07/16/2025
Requirements
Engineering for
Secure Software
Presented by: Kamulegeya
Grace
Adapted from Software Security E
ngineering: A Guide for Project Ma
nagers by Allen etal
07/16/2025
Introduction
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, etc.
They are not security requirements at all, but rather
implementation mechanisms that are intended to
satisfy unstated requirements, such as authenticated
access.
Security requirements that are specific to the
system and that provide for protection of essential
services and assets are often neglected.
Attacker perspective is often not considered.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Importance of requirements
engineering
Studies have shown that it costs more to correct
requirements engineering problems once the
system has become operational than if they were
detected during requirements development.
Other studies have shown that reworking
requirements, design, and code defects on most
software development project accounts for 40 to 50
percent of the total project effort.
These figures show that by the time an application
is installed in its operational environment, it is very
difficult and expensive to significantly improve its
security.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Effects of requirements
problems
Projects are significantly over budget, go past
schedule, have significantly reduced scope, or
are cancelled.
Development teams deliver poor-quality
applications.
Products are not significantly used once
delivered.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Problems faced by requirements
engineering on individual projects
Requirements identification typically does not include
all relevant stakeholders and does not use the most
modern or efficient techniques.
Requirements are often statements describing
architecture constraints or implementation
mechanisms rather than statements describing what
the system must do.
Requirements are often directly specified without any
analysis or modeling. When analysis is done, it is
usually restricted to functional end-user
requirements, ignoring
1. Quality requirements such as security
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Problems faced by requirements
engineering on individual projects
2. Other functional and nonfunctional requirements
and
3. Architecture, design, implementation, and
testing constraints.
Requirements specification is typically
haphazard, with specified requirements being
ambiguous, incomplete (e.g., nonfunctional
requirements are often missing), inconsistent,
not cohesive, infeasible, obsolete, neither
testable nor capable of being validated, and
not usable by all of their intended audiences.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Problems faced by requirements
engineering on individual projects
Requirements management is typically weak,
with ineffective forms of data capture (e.g., in
one or more documents rather than in a
database or tool) and missing attributes.
It is often limited to tracing, scheduling, and
prioritization, without change tracking or other
configuration management.
Alternatively, it may be limited to the
capabilities provided by a specific too, with little
opportunity for improvement.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Quality requirements
These include
1. Performance
2. Safety
3. Security
4. Reliability
5. And maintainability
These are often neglected in comparison to functional end-
user requirements due to:
The desire to keep costs down
and meet aggressive schedules
Some quality requirements are nonfunctional
requirements, but others describe system functionality,
even though it may not contribute directly to end-user
requirements. Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Security requirements
engineering
Security requirements are often developed independent
of other requirements engineering activities.
Specific security requirements are often neglected, and
functional requirements are specified in blissful ignorance
of security aspects.
Security requirements development should be planned
as iterative activities, taking place as change occurs to
dynamically changing operational and business goals.
It should dwell on what the system should not do as
opposed to the attention that is usually paid on what a
system should do (functionality)
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Security requirements
engineering
Users have implicit assumptions for the systems
and software applications they use.
They expect those products to be secure and
are surprised when they are not.
These assumptions need to be translated into
security requirements for the software systems
when they are under development.
Its important for requirements engineers to
think about the attacker’s perspective and not
just the functionality of the system from the
end-user’s perspective.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Security requirements
engineering
Techniquesused to define the attacker’s
perspective.
1. Attack patterns (covered in previous lectures)
2. Misuse and abuse cases (to be covered in this
lecture)
3. Attack trees
4. Threat modelling
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Ensuring security requirements
Techniques to ensure that resulting products
effectively meets security requirements.
1. Comprehensive, Lightweight Application Security
Process (CLASP) approach to security engineering.
It’s a lifecycle process that suggests a number of
different activities across the development life cycle
in an attempt to improve security. Among these is a
specific approach to security requirements.
2. Security Quality Requirements Engineering
(SQUARE). This process is aimed specifically at
security requirements engineering.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Ensuring security requirements
3. Core security requirements artifacts. This
approach takes an artifact view and starts
with the artifacts that are needed to achieve
better security requirements.
It provides a framework that includes both
traditional requirements engineering
approaches to functional requirements and an
approach to security requirements engineering
that focuses on assets and harm to those
assets.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Misuse and abuse cases
Present a way to represent non-normative behavior
that is not normally described in use cases.
One of the goals is to help you to decide and
document how software should react to illegitimate
use.
Misuse(or abuse) cases can help you to begin to
see your software in the same light that attackers
do.
By thinking beyond normative features while
simultaneously contemplating negative or
unexpected events:
You can better understand how to create secure and
reliable software.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Security is not a set of features
Security is an emergent property of a system, not a
feature.
It cannot be bolted on after other software features are
codified.
nor can it be patched in after attacks have occurred in
the field.
Security must be built into the product from ground
up,
as a critical part of the design from the very beginning
(requirements specification)
and included in every subsequent development phase,
all the way through fielding a complete system.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Security is not a set of features
The best, most cost-effective approach to
software security incorporates thinking
beyond normative features and maintains
that thinking throughout the development
process.
Every time a new requirement, feature, or
use case is created, the developer or
security specialist should spend some time
thinking how that feature might be
unintentionally misused or intentionally
abused.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Thinking about what you can’t do
If the development process doesn’t address
unexpected or abnormal behavior, then the
attacker usually has plenty of raw material to
work with. For example;
They always probe well-known locations-boundary
conditions, edges, intersystem communication, and
system assumptions-in the course of their attacks.
They can try to undermine the assumptions on
which a system was built.
When we design and analyze a system, we are
in a great position to know our systems better
than potential attackers do.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Thinking about what you can’t do
We must leverage this knowledge to the
benefit of security and reliability, which we
can achieve by asking and answering the
following critical questions
1. Which assumptions are implicit in our
system?
2. Which kinds of things make our assumptions
false?
3. Which kinds of attack patterns will an
attacker bring to bear?
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Creating useful misuse cases
Theoretical methods require fully specifying a
system with rigorous formal models and logics,
but such activities are extremely time and
resource intensive.
The Simplest and most practical method for
creating misuse cases is through a process of
informed brainstorming.
A more practical approach teams security and
reliability experts with Subject matter experts
(SMEs). This approach relies heavily on expertise
and covers a lot of ground quickly.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Creating useful misuse cases
To guide brainstorming;
Software security experts ask many questions of a
system’s designers to help identify the places where
the system is likely to have weaknesses. This
activity mirrors the way attackers think.
Such brainstorming involves
a careful look at all user interfaces (including
environmental factors)
and considers events that developers assume a
person can’t or won’t do.(attackers, unfortunately,
can make these can’ts and won’ts happen)
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Creating useful misuse cases
The process of specifying abuse cases makes a
designer very clearly differentiate appropriate use
from inappropriate use.
To reach this point, however, the designer must ask
the right questions. For example:
How can the system distinguish between good input and
bad input?
Can it tell whether a request is coming from a legitimate
application or from a rogue application replaying traffic?
e.t.c
Attack patterns can provide some guidance in
developing misuse and abuse cases.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
Creating useful misuse cases
An attack pattern is a blueprint for creating an attack.
Patterns allow for a fair amount of variation on a theme.
They can take into account many dimensions, including
timing, resources required, techniques, and so forth.
A good approach to creating use cases requires a
combination of
security know-how
and subject matter expertise
to prioritize misuse cases as they are generated and to
strike a balance between cost and value.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
The SQUARE Process Model
Although, misuse and abuse cases can be used
as a stand-alone activity they are more effective
when developed as part of an overall security
requirements engineering process.
The Security Quality Requirements
Engineering (SQUARE) process is one of such.
It provides means for
1. Eliciting
2. Categorizing
3. And prioritizing security requirements for
information technology systems and
applications
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
The SQUARE Process Model
The focus of the model is to build
security concepts into the early stages of
the SDLC.
Can also be used
for documenting and analyzing the
security aspects of the system once they
are implemented in the field
And for steering future improvements and
modifications to those systems.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
07/16/2025
The SQUARE process
See the SQUARE Process.doc attachment.
Adapted from Software Security Engineerin
g: A Guide for Project Managers by Allen et
al
