Pictured here, Pradeep Khosla, Dean of the Carnegie Institute of Technology and Co-Director of CyLab.  

The tool to support the SQUARE process will only be available to ISAlliance members. How do I access the SQUARE Tool?

A prototype tool called T-SQUARE has been developed to support SQUARE. It primarily provides an organizational framework for the artifact documents, and it also provides default content for some of the steps. It does not perform sophisticated functions such as requirements analysis. This prototype tool is undergoing further development so that it provides better support to the SQUARE process and is more attractive to users.
 

WHAT IS SQUARE? 

Security Quality Requirements Engineering (SQUARE) is a model developed at Carnegie Mellon University by Nancy Mead as part of a research project with Donald Firesmith and Carol Woody of the Software Engineering Institute. SQUARE is a process that provides a means for eliciting, categorizing, and prioritizing security requirements for information technology systems and applications. The focus of this methodology is to build security concepts into the early stages of the development life cycle. The model can also be used for documenting and analyzing the security aspects of fielded systems and for steering future improvements and modifications to those systems. 

Overview

Subsequent to initial development, SQUARE was applied in a series of client case studies. Carnegie Mellon graduate students worked on this project during the summer and fall of 2004 and the summer of 2005. The case study results were published [Chen 04, Gordon 05, Xie 04]. Prototype tools were also developed to support the process. The draft process was revised based on the case studies; the revised process is shown in [. In principle, Steps 1-4 are actually activities that precede security requirements engineering but are necessary to ensure that it is successful. A detailed discussion of the method can be found in [Mead 05a].

Table 1. SQUARE Process

How to Apply SQUARE

The SQUARE process is best applied by the project’s requirements engineers and security experts, in the context of supportive executive management and stakeholders. We believe the process works best when elicitation occurs after risk assessment (Step 4) has been done and when security requirements are specified prior to critical architecture and design decisions. Thus critical business risks will be considered in the development of the security requirements.

Step 1, Agree on Definitions, is needed as a prerequisite to security requirements engineering. On a given project, team members will tend to have definitions in mind, based on their prior experience, but those definitions will not necessarily agree [Woody 05]. For example, to some government organizations, security has to do with access based on security clearance levels, whereas to others security may have to do with physical security or cyber security. It is not necessary to invent definitions. Most likely, sources such as IEEE and SWEBOK will provide a range of definitions to select from or tailor. A focus group meeting with the interested parties will most likely enable the selection of a consistent set of definitions for the security requirements activity.

Step 2, Identify Security Goals, should be done at the organizational level and is needed to develop the information system. This provides a consistency check with the organization’s policies and operational security environment. Different stakeholders will likely have different goals. For example, a stakeholder in human resources may be concerned about maintaining the confidentiality of personnel records, whereas a stakeholder in a financial area may be concerned with ensuring that financial data is not accessed or modified without authorization. It is important to have a representative set of stakeholders, including those with operational expertise. Once the goals of the various stakeholders have been identified, they will need to be prioritized. In the absence of consensus, an executive decision may be needed to prioritize these goals.

Step 3, Develop Artifacts, is necessary to support all the subsequent activities. It is often the case that organizations do not have a documented concept of operations for a project, succinctly stated project goals, documented normal usage and threat scenarios, misuse cases, and other documents needed to support requirements definition. This means that either the entire requirements process is built on a foundation of sand or a lot of time is spent backtracking to try to obtain such documentation.

Step 4, Perform Risk Assessment, requires an expert in risk assessment methods, the support of the stakeholders, and the support of a requirements engineer. There are a number of risk assessment methods to select from. A specific method can be recommended by the risk assessment expert, based on the needs of the organization. The artifacts from Step 3 provide the input to the risk assessment process. The outcomes of the risk assessment can help in identifying the high-priority security exposures. Organizations that do not perform risk assessment typically do not have a logical approach to considering organizational risk when identifying security requirements but tend to select mechanisms, such as encryption, without really understanding the problem that is being solved.

Step 5, Select Elicitation Technique, becomes important when there are several classes of stakeholders. A more formal elicitation technique, such as ARM [Hubbard 99], JAD [Wood 89], or structured interviews can be effective in overcoming communication issues when there are stakeholders with different cultural backgrounds. In other cases, elicitation may simply consist of sitting down with a primary stakeholder to try to understand that stakeholder’s security requirements needs.

Step 6, Elicit Security Requirements, is the actual elicitation process using the selected technique. Most elicitation techniques provide detailed guidance on how to perform elicitation. This builds on the artifacts that were developed in earlier steps, such as misuse and abuse cases, attack trees, threats, and scenarios.

Step 7, Categorize Requirements, allows the requirements engineer to distinguish among essential requirements, goals (desired requirements), and architectural constraints that may be present. Requirements that are actually constraints typically occur when a specific system architecture has been chosen prior to the requirements process. This is good, as it allows assessment of the risks associated with these constraints. This categorization also helps in the prioritization activity that follows.

Step 8, Prioritize Requirements, depends not only on the prior step but may also involve performing a cost/benefit analysis to determine which security requirements have a high payoff relative to their cost.

Step 9, Requirements Inspection, can be done at varying levels of formality, from Fagan Inspections to peer reviews. Once inspection is complete, the organization should have an initial set of prioritized security requirements. It should also understand which areas are incomplete and must be revisited at a later time. Finally, the organization should understand which areas are dependent on specific architectures and implementations and should expect to revisit those as well.

How to Measure and Manage

Although quantitative measures do not exist, the clients for the case studies mentioned earlier recognized the value of the new security requirements and have started to take steps to incorporate them into the system. Important considerations for management are the amount of resources to be invested in this activity and in the implementation of the resultant requirements [Xie 04]. Management also needs to provide insights into the business environment and drivers and the mission of the system under development, as well as input as to the essential services and assets of the system.

Additional Resources for SQUARE

The following presentations and activities were intended to initiate further discussion on the management issues addressed by the SQUARE process:

·         “Considering Operational Security Risks During Systems Development,” SEPG 2004, Orlando, Florida, March 9, 2004 [Alberts 04]

·         “Can Secure Systems be Built Using Today’s Development Processes?” European SEPG, London, England, June 17, 2004 [Woody 04]

A workshop on Requirements for High Assurance Systems (RHAS '04) was held in conjunction with the International Conference on Requirements Engineering on September 6, 2004. The workshop proceedings for this and prior RHAS workshops were published by the SEI [SEI 04]. SQUARE was presented at an International Conference on Software Engineering (ICSE) workshop as well [Mead 05b]. The definitive technical report on SQUARE was published this year [Mead 05a].

Tools

A prototype tool called T-SQUARE has been developed to support SQUARE. It primarily provides an organizational framework for the artifact documents, and it also provides default content for some of the steps. It does not perform sophisticated functions such as requirements analysis. This prototype tool is undergoing further development in 2005-2006, so that it provides better support to the SQUARE process and is more attractive to users.

Results to Expect

When SQUARE is applied, the user should expect to have identified and documented relevant security requirements for the system or software that is being developed. SQUARE may be more suited to a system under development than one that has already been fielded, although it has been used both ways.

Relevant Metrics

There is no formal measurement data at this time, although clients have been satisfied that security requirements were identified that might not have been discovered otherwise and have taken steps to implement them.

Maturity of Practice

There have been several successful pilot projects using several versions of the SQUARE method while it has been under development. It is not a mature practice, however.

Case Studies

The SQUARE Methodology has undergone several case studies conducted by graduate students at Carnegie Mellon University [Chen 04, Gordon 05]. The goals of the case studies were to experiment with each step of the SQUARE process, make recommendations, and determine the feasibility of integrating SQUARE into standardized software development practices. The case studies involved real-world clients that were developing large-scale IT projects. The clients included an IT firm in Pittsburgh, Pennsylvania, a federal government research institute, and a department of the federal government.

Acme Corporation

All three case studies included Acme Corporation (Acme)¹, a private company headquartered in Pittsburgh. It provides technical and management services to various public sectors and a number of diversified private sectors. Its product under study, the Asset Management System (AMS)², provides a tool for companies to make strategic allocations and planning of their critical IT assets. It provides specialized decision support capabilities via customized views. AMS provides a graphical interface to track and analyze the state of important assets. The security requirements surrounding the AMS are the subject of these graduate case studies.

It is important to note here that the AMS is a fielded system, undergoing major upgrades, so the results from these case studies may not be a perfect fit for determining SQUARE’s usefulness in a pre-production environment. However, the willingness of the client to participate was an important factor in its selection. Further, the results of these case studies are important in beginning to understand the effectiveness of the nine steps of the SQUARE process.

Output from SQUARE Steps

In each case study, the student teams focused part of their efforts on researching various methods to conduct each step. In some cases, redundant work was completed to determine which methods might lend themselves better to SQUARE. In order to provide concrete examples of the nine SQUARE steps, we present here a sample of the output from each individual step (all taken from the case studies) to demonstrate how SQUARE looks in action.

Step 1: Agree on Definitions

The student teams worked with the client to agree on a common set of security definitions in order to create a common base of understanding. The following is a minute subset of the definitions that were agreed upon:

·        access control: Access control ensures that resources are granted only to those users who are entitled to them.

·        access control list: A table that tells a computer operating system which access rights or explicit denials each user has to a particular system object, such as a file directory or individual file.

·        antivirus software: A class of program that searches hard drives and floppy disks for any known or potential viruses.

The full set of definitions was drawn from resources such as Carnegie Mellon University, industry, and dictionaries.

Step 2: Identify Safety and Security Goals

Here, the project team worked with the client to flesh out safety and security goals that mapped to the company’s overall business goal. The business and security goals were defined as follows:

·        Business Goal of AMS: To provide an application that supports asset management and planning.

·        Safety and Security Goals: Three high-level safety and security goals were derived for the system:

1.      Management shall exercise effective control over the system’s configuration and usage.

2.      The confidentiality, accuracy, and integrity of the AMS shall be maintained.

3.      The AMS shall be available for use when needed.

Step 3: Developing Artifacts

Architectural diagrams, use cases, misuse cases, attack trees, and essential assets and services were documented in this portion of SQUARE. For instance, an attack scenario was documented in the following way:

System administrator accesses confidential information

1.      by being recruited OR

1.      by being bribed OR

2.      by being threatened OR

3.      through social engineering OR

2.      by purposefully abusing rights

This step creates a volume of important documentation that serves as vital input into following steps.

Step 4: Perform Risk Assessment

The risk management techniques that were field tested were selected after a literature review was completed. This literature review examined the usefulness and applicability of eight risk assessment techniques:

1.      General Accounting Office Model [GAO 99]

2.      National Institute of Standards Model [Stoneburner 02]

3.      NSA’s INFOSEC Assessment Methodology [NSA 04]

4.      Shawn Butler’s Security Attribute Evaluation Method [Butler 02]

5.      Carnegie Mellon’s Vendor Risk Assessment and Threat Evaluation [Lipson 01]

6.      Yacov Haimes’s Risk Filtering, Ranking, and Management Model [Haimes 04]

7.      Carnegie Mellon’s Survivable Systems Analysis Method [Mead 02]

8.      Martin Feather’s Defect Detection and Prevention Model [Cornford 04]

Each method was ranked in four categories:

1.      suitability for small companies

2.      feasibility of completion in the time allotted

3.      lack of dependence on historical threat data

4.      suitability in addressing requirements

After averaging scores from the four categories, NIST’s and Haimes’s models were selected as useful techniques for the risk assessment step. Many threat scenarios were brainstormed during this step. Some of this input came from the attack tree and misuse case documentation provided from Step 4. The two independent risk assessment analyses produced a useful risk profile for the company’s system. The two most meaningful findings were

1.      Insider threat poses the most important risk to the AMS.

2.      Because of weak controls, it is easy for an insider or passerby to defeat authentication.

All findings from the risk assessment, along with the findings from the essential services and asset identification process completed in the artifact generation stage, were used to determine the priority level associated with each of the nine requirements.

Step 5: Select Elicitation Techniques

For this step, student teams were tasked with testing various elicitation techniques and models for the overall benefit of SQUARE. Although this task may appear to be straightforward, it is often the case that multiple techniques will likely work for the same project. The difficulty is in choosing a technique that can adapt to the number and expertise of stakeholders, the size and scope of the client project, and the expertise of the requirements engineering team. It is extremely unlikely that any single technique will work for all projects under all circumstances, though previous experience has shown that the Accelerated Requirements Method (ARM) has been successful in eliciting security requirements.

The following is a sample of elicitation techniques that may be appropriate:

·         structured/unstructured interviews

·         use/misuse cases [Jacobson 92]

·         facilitated meeting sessions, such as Joint Application Development and the Accelerated Requirements Method [Wood 89, Hubbard 99]

·         Soft Systems Methodology [Checkland 89]

·         Issue-Based Information Systems [Kunz 70]

·         Quality Function Deployment [QFD 05]

·         Feature-Oriented Domain Analysis [Kang 90]

·         Controlled Requirements Expression [Mullery 79]

·         Critical Discourse Analysis [Schiffrin 94]

Steps 6 and 7: Elicit and Categorize Safety and Security Requirements

Nine security requirements were derived and then organized to map to the three higher level security goals. Two of the nine requirements are

·         Req 1: The system is required to have strong authentication measures in place at all system gateways/entrance points (maps to Goals 1 and 2).

·         Req 3: It is required that a continuity of operations plan (COOP) be in place to assure system availability (maps to Goal 3).

The nine security requirements made up the heart of the security requirements document that was ultimately delivered to the client.

Step 8: Prioritize Requirements

In the first case study, the nine security requirements were prioritized based on the following qualitative rankings:

·         Essential: Product will be unacceptable absent these requirements.

·         Conditional: Requirement would enhance safety and security, but the product would not be unacceptable in its absence.

·         Optional: Requirement may or may not be necessary.

Recalling the requirements identified in Steps 6-7, Req 1, which dealt with authentication at borders and gateways, was deemed essential because of its importance in protecting against the authentication-related risks outlined as a major risk in the risk assessment. Req 3, dealing with continuity of operations planning, is still seen as an important element and worth considering, but was found to be an optional requirement relative to the other eight requirements. That is, though COOP plans are valuable, the risk assessment phase found that the greater threats to the system were those that dealt with unauthorized disclosure of information, rather than availability attacks.

Another case study team utilized the Analytic Hierarchy Process (AHP) methodology to prioritize requirements and found it to be very successful both in client acceptance and in its ability to handle security requirements [Karlsson 97, Saaty 80]. AHP is a technique for decision making in situations in which multiple objectives are present. The method calculates the relative value and cost among security requirements. By using AHP, the requirements engineer can also confirm the consistency of the stakeholders’ results, which can prevent subjective judgment errors and increase the likelihood that the results are more reliable. The stakeholders found AHP valuable not only for its ability to quickly prioritize the security requirements but also because of the internal discussion that is stimulated.

Step 9: Requirements Inspection

The case study teams experimented with different inspection techniques and had different levels of success with each. None of the inspection techniques that were used were sufficiently effective in identifying defects in the security requirements, and the teams do not recommend their use in the future. Instead, the teams recommend that future iterations of SQUARE experiment with the Fagan inspection technique, which is a highly structured and proven technique for requirements inspection.

In one case study instance, each team member played a role in inspecting the quality of the team’s work and deliverables. A peer review log was created to document what had been reviewed and was used to maintain a log of all problems, defects, and concerns. Each entry in the log was numbered and dated, addressing the date, origin, defect type, description, severity, owner, reviewer, and status. Each piece of documentation was assigned to an owner, who was held responsible for making sure that defects were fixed. This step was used as a sanity check to ensure that the team’s work met the group’s quality goals and expectations.

Managing and Assessing SQUARE

The final output to the client was a security requirements document that began by addressing the business goal, followed by the three security goals that supported this business goal, the nine categorized security requirements that supported the higher level security goals, and a list of application- and configuration-specific recommendations to meet these security requirements. From here, a responsible firm would use this document in the early stages of the development life cycle to make sure that security requirements are built into the planning of the project. Once a system has been deployed, the firm can look back to its requirements documentation to analyze whether it meets its requirements and thus satisfies its security goals to protect the system’s business function. As change occurs—be it a configuration concern in the system, the organization’s risk profile, or overall business goal—the process can be reused to plan how the changing environment will affect the security concerns of the system. SQUARE is thus easily reapplied to a system as needed.

Because the key players include a dedicated task force with knowledge of security who team with a group of knowledgeable client personnel, conducting a SQUARE assessment only requires that a firm have the time and human resources available to assist a group of outside analysts. Further, a firm knowledgeable in security could be in a position to conduct SQUARE analysis without outside help. The first graduate team spent a significant amount of time with the client in helping the client develop documentation. Many firms may complete this step before the SQUARE analysis begins. The second phase team made use of this documentation and was able to complete its assessment with very little client/analyst interaction. The SQUARE analysis was very lightweight and unobtrusive to the client in this regard. The third team worked with the initial client and two other clients, focusing on Steps 5 through 9.

Glossary

References

Copyright 

Carnegie Mellon University SEI-authored documents are sponsored by the U.S. Department of Defense under Contract FA8721-05-C-0003. Carnegie Mellon University retains copyrights in all material produced under this contract. The U.S. Government retains a non-exclusive, royalty-free license to publish or reproduce these documents, or allow others to do so, for U.S. Government purposes only pursuant to the copyright license under the contract clause at 252.227-7013.

Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works.

For inquiries regarding reproducing this document or preparing derivative works of this document for external and commercial use, including information about “Fair Use,” see the Permissions page on the SEI web site. If you do not find the copyright information you need on this web site, please consult your legal counsel for advice.