SQUARE-Process
Presented by: Kamulegeya Grace
Adapted from:https://buildsecurityin.us-cert.gov/bsi/articles/best-
07/16/2025 practices/requirements/232-BSI.html
Introduction
System Quality Requirements Engineering
(SQUARE) is a process model that was
developed at Carnegie Mellon University
It provides a means
for eliciting,
categorizing,
and prioritizing
security requirements for information
technology systems and applications.
Adapted from:https://buildsecurityin.us-
cert.gov/bsi/articles/best-practices/
07/16/2025 requirements/232-BSI.html
FOCUS OF THE MODEL
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.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
The draft process was revised and baselined
after the case studies were completed;
the baselined process is shown in Table 1
attached as SQUARE Process.pdf.
In principle, Steps 1-4 are actually activities
that precede security requirements
engineering but are necessary to ensure that
it is successful
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
A Brief Description of SQUARE
The process works best when elicitation
occurs after risk assessment (Step 4) has
been done and when security requirements
are specified before critical architecture and
design decisions.
Thus critical security risks to the business
will be considered in the development of the
security requirements.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Step 1
Agree on Definitions, is needed as a
prerequisite to security requirements
engineering.
On a given project, team members tend to
have definitions in mind, based on their prior
experience, but those definitions often differ.
For example, for some government
organizations, security has to do with access
based on security clearance levels, whereas
for others security may have to do with
physical security or cyber security.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Step 1
It is not necessary to invent definitions.
Sources such as the Institute for Electrical
and Electronics Engineers (IEEE) and the
Software Engineering Body of Knowledge
(SWEBOK) provide a range of definitions to
select from or tailor.
A focus group meeting with the interested
parties most likely enables the selection of a
consistent set of definitions for the security
requirements activity.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Step 2
Identify Assets and Security Goals, should be done at
the organizational level and is needed to support
software development in the project at hand.
This provides a consistency check with the
organization’s policies and operational security
environment.
Different stakeholders usually have different goals.
For example, a stakeholder in human resources may be
concerned about maintaining the confidentiality of
personnel records, so from their point of view the
personnel records are an asset, whereas a stakeholder
in a financial area may be concerned with ensuring
that financial data is not accessed or modified without
authorization, so they will feel that financial data are
an asset.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Step 2
It is important to have a representative set of
stakeholders, including those with
operational expertise.
Once the assets and goals of the various
stakeholders have been identified, they need
to be prioritized.
In the absence of consensus, an executive
decision may be needed to prioritize these
assets and goals.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Step 3 (Develop Artifacts)
Develop Artifacts, is necessary to support all
subsequent security requirements engineering
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 or abuse cases,
and other documents needed to support
requirements definition.
This means that either the entire requirements process
is built on unstated assumptions or a lot of time is spent
backtracking to try to obtain such documentation.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Step 4 (Perform Risk Assessment)
It requires an expert in risk assessment
methods, the support of the stakeholders, and
the support of a security requirements
engineer.
There are a number of risk assessment
methods to select from.
The risk assessment expert can recommend a
specific method based on the needs of the
organization.
The artifacts from Step 3 provide the input to
the risk assessment process.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Step 4 (Perform Risk Assessment)
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 risks
when identifying security requirements but
tend to select specific solutions or
technologies, such as encryption, without
really understanding the problem that is
being solved.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Step 5 (Select Elicitation Technique)
It becomes important when there are diverse
stakeholders.
A more formal elicitation technique, such as the
Accelerated Requirements Method,
Joint Application Design ,
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.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Step 6 (Elicit Security Requirements)
This 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.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Step 7 (Categorize Requirements)
It allows the security 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.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Step 8 (Prioritize Requirements)
This 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.
Of course prioritization may also depend on
other consequences of security breaches,
such as loss of life, loss of reputation, and
loss of consumer confidence
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Step 9 (Inspect Requirements)
This can be done at varying levels of formality,
from Fagan inspections (a highly structured and proven
technique for requirements inspection)
to peer reviews.
Once inspection is complete, the project team 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 project team should understand which
areas are dependent on specific architectures and
implementations and should plan to revisit those as
well.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Square Tools
A prototype tool 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 provides limited support for sophisticated
functions such as traceability and prioritization.
This prototype tool is undergoing redevelopment
in 2008-2009 so that it will be more robust,
provide better support to the SQUARE process,
and be more attractive to users.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Expected Results
When you apply SQUARE,
you can expect to have relevant security
requirements identified and documented for the
system or software that is being developed.
SQUARE is more suited to a system under
development than one that has already been
fielded, although it has been used for both.
Although quantitative measures do not exist, case
study clients recognized the value of the new
security requirements and have taken steps to
incorporate them into their system specifications.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Expected Results
Our experience with SQUARE suggests that the
system and its elements have to be considered within
the context or environment in which it operates.
For example, a system that operates on a single
isolated workstation will have very different security
requirements from a similar system that is Web
based.
In a similar fashion, a medical information system
will have different security requirements for
workstations that are isolated in a physician’s office
than for those that are in a public area in a hospital.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Expected Results
These differences should be accounted for in
the artifacts developed in Step 3, for example
in usage scenarios and misuse or abuse cases.
When the context changes on a project, you
should revisit the security requirements and
reapply the SQUARE process. It may be that a
subset of the SQUARE steps will be sufficient
for this purpose, but we do not yet have
enough experience with subsequent
applications of SQUARE to the same system to
make that determination.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Output from SQUARE Steps
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.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE PROCESS IN ACTION
Step 1: Agree on Definitions
We worked with the client to agree on a common set of security
definitions to create a common base of understanding. The
following is a small subset of the definitions that were agreed on:
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 memory for any known or potential viruses.
The full set of definitions was drawn from resources such as
IEEE, Carnegie Mellon University, industry, and dictionaries.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE PROCESS IN ACTION
Step 2: Identify Safety and Security Goals
We worked with the client to flesh out security goals that
mapped to the company’s overall business goals. This is one
example set of goals:
Business Goal of AMS(Asset Management System): 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:
Management shall exercise effective control over the
system’s configuration and use.
The confidentiality, accuracy, and integrity of the AMS shall
be maintained.
The AMS shall be available for use when needed.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE
Step 3: Develop
PROCESS
Artifacts IN ACTION
Architectural diagrams, use cases, misuse cases, abuse
case diagrams, 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
by being recruited OR
by being bribed OR
by being threatened OR
through social engineering OR
by purposefully abusing rights
An example abuse case diagram is shown in Figure 1.
Figure 1. Abuse case example
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
This step creates needed documentation that
serves as input into the following steps.
Step 4: Perform Risk Assessment
The risk assessment techniques that were
field tested were selected after completing a
literature review. This review examined the
usefulness and applicability of eight risk
assessment techniques:
General Accounting Office Model [GAO 99]
National Institute of Standards and
Technology (NIST) Model [Stoneburner 02]
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
NSA’s INFOSEC Assessment Methodology
[NSA 04]
Shawn Butler’s Security Attribute Evaluation
Method [Butler 02]
Carnegie Mellon’s Vendor Risk Assessment
and Threat Evaluation [Lipson 01]
Yacov Haimes’s Risk Filtering, Ranking, and
Management Model [Haimes 04]
Carnegie Mellon’s Survivable Systems
Analysis Method [Mead 02]
Martin Feather’s Defect Detection and
Prevention Model [Cornford 04]
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
Each technique 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
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE PROCESS IN ACTION
Step 5: Select Elicitation Techniques
For this step, teams tested various elicitation
techniques and models.
It is often the case that multiple techniques
will 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.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE PROCESS IN ACTION
It is extremely unlikely that any single
technique will work for all projects under all
circumstances, though our experience has
shown that the Accelerated Requirements
Method [Hubbard 00] has been successful in
eliciting security requirements.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE PROCESS IN ACTION
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]
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE PROCESS IN ACTION
Steps 6 and 7: Elicit and Categorize Safety and Security Requirements
Nine security requirements were identified and then
organized to map to the three high-level security goals
(see Step 2). Some of the requirements were
Req 1: The system is required to have strong
authentication measures in place at all system gateways
and entrance points (maps to Goals 1 and 2).
Req 2: The system is required to have sufficient process-
centric and logical means to govern which system
elements (data, functionality, etc.) users can view,
modify, and/or interact with (maps to Goals 1 and 2).
Req 3: A continuity of operations plan (COOP) is
required to assure system availability (maps to Goal 3).
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE PROCESS IN ACTION
Req 6: It is required that the system’s
network communications be protected from
unauthorized information gathering and/or
eavesdropping (maps to Goals 1 and 2).
The nine security requirements were central
to the security requirements document that
was ultimately delivered to the client.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE PROCESS IN ACTION
In the first case study, the nine security
requirements were prioritized based on the
following qualitative rankings:
1. Essential: Product will be unacceptable if
this requirement is absent.
2. Conditional: Requirement enhances security,
but the product is acceptable if this
requirement is absent.
3. Optional: Requirement is clearly of lower
priority than Essential and Conditional
requirements.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE PROCESS IN ACTION
Req 1 from Steps 6 and 7, which dealt with
authentication at borders and gateways, was deemed
essential because of its importance in protecting
against the high-impact, authentication-related risks
identified in the risk assessment.
Req 3, dealing with continuity of operations
planning, was still seen as an important element and
worth considering, but it 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 greater threats to the
system resulted from unauthorized disclosure of
information than from availability attacks.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE PROCESS IN ACTION
Step 9: Inspect Requirements
We experimented with different inspection
techniques and had varying levels of success
with each.
None of the inspection techniques were
sufficiently effective in identifying defects in
the security requirements.
Instead, we recommend experimenting with
the Fagan inspection technique.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE PROCESS IN ACTION
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 entry was assigned to an owner, who was
responsible for making sure that defects were fixed. This
step was used as a sanity check to ensure that the
system met quality goals and expectations.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE Final Results
The final output to the client was a security
requirements document.
The client could then use this document in the
early stages of the development life cycle to
make sure that security requirements were
built into project plans.
Once a system has been deployed, the
organization can look back to its requirements
documentation to analyze whether it met its
requirements and thus satisfied its security
goals.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
SQUARE Final Results
As change occurs—be it a configuration concern in
the system, the organization’s risk profile, or a
business goal—the SQUARE process can be reused
to determine how the change might affect the
system’s security requirements. SQUARE can thus
be 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.
07/16/2025 Adapted from:https://buildsecurityin.us-cer
t.gov/bsi/articles/best-practices/requireme
