Software Security
Requirements
Outlin
e
• Software requirements elicitation
• Quality criteria for requirements
• Software security requirements
• Security requirements examples
University of 2
Adelaide
Software Development Phases
University of 3
Adelaide
Software Requirement
Engineering
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 4
Adelaide
Software Requirements
Elicitation
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 5
Adelaide
Software Requirements
Elicitation
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 6
Adelaide
Software
Stakeholder
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 7
Adelaide
Software Customer
[A customer is an] individual or organization
that derives either direct or indirect benefit from
a product. Software customers might request,
pay for, select, specify, use, or receive the
output generated by a software product.”
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 8
Adelaide
Requirements Elicitation
Techniques
Source: Top 5 Requirements Elicitation Techniques for Business Analysts, Techcanvass
University of 9
Adelaide
Interviews
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 10
Adelaide
Workshops
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 11
Adelaide
Observations
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 12
Adelaide
Brainstorming/focus group
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 13
Adelaide
Document Analysis
most commonly used/easiest method to collect software requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 14
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 15
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 16
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 17
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 18
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 19
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 20
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 21
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 22
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 23
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 24
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 25
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 26
Adelaide
Quality criteria for
requirements
Source: Requirements engineering by Dagmar Monett – Berlin School of Economics and Law
University of 27
Adelaide
Security Quality Requirements
Engineering
• Security Quality Requirements Engineering (SQUARE)
• Developed by the Networked Systems Survivability
program at the SEI, Carnegie Mellon University.
– A method to elicit, categorise, and prioritise security requirements for
software systems and applications.
– This method focuses on developing security concepts at the
early stages of a software system’s development life cycle.
– The method is also used for documenting and analysing the
security aspects of existing systems for modifications and
evolution.
– This method can also be used with existing requirements
engineering process
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 2
SQUARE – Some Details
• Who is involved?
– Stakeholders of the project
– Requirement engineers with security expertise
• In SQUARE, security requirements are:
– Treated at the same time as the system’s functional
requirements, AND
– Specified in the early stages of the SDLC (software
development lifecycle)
– Specified in similar ways as software requirements
engineering and practices
– Determined through a process of nine discrete steps
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 2
SQUARE Steps
• 1. Agree on definitions.
• 2. Identify assets and security goals.
• 3. Develop artifacts to support security requirements definition.
• 4. Assess risks.
• 5. Select elicitation technique(s).
• 6. Elicit security requirements.
• 7. Categorize requirements.
• 8. Prioritize requirements.
• 9. Inspect requirements.
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 3
SQUARE Steps
1. the first task for the organization is to agree on a common set of security
definitions, followed by the definition of organizational security goals.
2. These security goals may be derived from business application goals, potential
threats to project assets, and management controls and policy.
3. The requirements engineer can then develop artifacts (network maps and
diagrams, attack trees, and use/misuse cases) that will aid in the elicitation of
security requirements.
4. Next, a formal risk assessment allows the organization to understand how the
likelihood and impact of various threats can affect the project’s security goals
and assets.
5. At this point in the SQUARE process, the requirements engineer must select one
or more requirements-elicitation techniques appropriate for the
organization’s culture, expertise, level of security required, and nature of the
system being developed.
6. The selected techniques are subsequently used to elicit an initial set of
security requirements in the form of operational constraints on the system. An
example of such a requirement is “The system shall only reveal employee salary
information to members of the Human Resources Department.”
7. These requirements are then categorized, prioritized, and formally
inspected for correctness in the remaining steps of SQUARE.
8. The final output of the process is a security requirements document that
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
satisfies the security goals of the project, contains clear and verifiable
presentation. 3
Different Aspects of SQUARE
Steps
Step Name Input Techniques
Agree on definitions
Participants/Outputs
Candidate definitions Structured Stakeholders,
from IEEE and other interviews, focus requirements
standards group engineer/Agreed-to-
definitions
Identify assets and Definitions, candidate Facilitated work Stakeholders,
security goals goals, business session, surveys, requirements engineer/
drivers, policies and interviews Assets and goals
procedures
Develop artifacts to Potential artifacts Work session Requirements
support security (e.g., scenarios, engineer/ Scenarios,
requirements misuse cases, misuse cases, models,
definition templates, forms) templates, forms
Perform risk assessment Misuse cases, Risk assessment Requirements engineer
scenarios, security method, analysis of & expert stakeholders/
goals anticipated risk against risk assessments
organizational risk results
tolerance, threat
analysis
Select Goals, definitions, Work session Requirements
elicitation candidate techniques, engineers/ Selected
techniques expertise of elicitation techniques
stakeholders,
organizational style,
culture, level of
security needed,
cost/benefit
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 3
Different Aspects of SQUARE
Steps
Step Name Input Techniques Participants/Outputs
Elicit security Artifacts, risk Application Stakeholders facilitated
requirements assessment results, Development (JAD), by requirements
selected techniques interviews, surveys, engineer/Initial cut at
model-based analysis, security requirements
checklists, lists of
reusable requirements
types, document
reviews
Categorize requirements Initial Work session using a Requirements
as to level (system, requirements, standard set of engineer, other
software, etc.) and architecture categories specialists as
whether they are needed/Categorized
requirements or other requirements
kinds of constraints
Prioritize requirements Categorized Prioritization methods Stakeholders facilitated
requirements and risk such as Analytical by requirements
assessment results Hierarchy Process engineer/ Prioritized
(AHP), Triage, Win- Win requirements
Inspect requirements Prioritized Inspection method such Inspection team/Initial
requirements, as Fagan, peer reviews selected requirements,
candidate formal documentation of
inspection technique decision- making
process and rationale
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 3
SQUARE – Step 1: Agree on Definitions
• Goal: to guarantee effective and clear communication throughout the
requirements engineering process
• Content: agree on a common set of terminology and definitions.
• Why?:
o differences in expertise, knowledge, and experience
o ambiguity in terms
• Reuse public resources of security terms:
o Software Engineering Body of Knowledge (SWEBOK)
o IEEE 610.12 Standard Glossary of Software Engineering
Terminology
e.g., ambiguity of term access controls:
• One stakeholder: it is a set of policies that governs which users
may be granted access to which resources
• Another stakeholder: it is the software elements in the system
that actually implements this functionality.
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 3
SQUARE - Step 2: Identify Security
Goals
• Goal: formally agree on a set of prioritized security goals
• Content: Identify and prioritize the overall security goals
• Why?:
o different stakeholders will likely have different security goals,
e.g., confidentiality of personnel records or authorization in financial
data
o security goals of the stakeholders may also conflict with one
another,
e.g., security guys: strong security vs marketing: high performance
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 3
SQUARE - Step 3: Develop Artifacts
• Goal: generate a complete set of artifacts of the system
• Content: identify and collect as many artifacts as possible
• Why?:
o prepare for generating security requirements
o prepare for risk assessment
• Types of artifacts:
o system architecture diagrams;
o use case scenarios/diagrams;
o misuse case scenarios/diagrams;
o attack trees;
o standardized templates and forms;
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 3
SQUARE - Step 3: Develop Artifacts
Example system architecture diagram
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 3
SQUARE - Step 3: Develop Artifacts
An attacker’s goal is listed as the root node;
Tree leaves represent different ways to achieve that goal
Example Attack Tree
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 3
SQUARE - Step 3: Develop Artifacts
Sample Use Case Diagram
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 3
SQUARE - Step 3: Develop Artifacts
Example of misuse
Source: Sindre, G. and Opdahl, A. L., 2005
4
SQUARE - Step 4: Perform Risk
Assessment
• Goal: identify the potential vulnerabilities and threats that face the system
• Content: identify and classify the likelihood of vulnerabilities/threats
• Why?:
o implement logical security requirements or countermeasures, e.g.,
honeypot
o to prioritize the security requirements
Example risk assessment
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 4
SQUARE - Step 5: Select Elicitation
Technique
• Goal: select an elicitation technique that is suitable for the client
organization and project
• Content: choosing a technique that can adapt to:
o the number and expertise of stakeholders,
o size and scope of the client project, and
o expertise of the requirements engineering team.
• A sample of elicitation techniques:
o Structured/unstructured interviews
o Use/misuse cases
o Facilitated meeting sessions, such as Joint Application
Development and the Accelerated Requirements Method
o Soft Systems Methodology
o Issue-Based Information Systems
o Quality Function Deployment
o Feature-Oriented Domain Analysis
o Controlled Requirements Expression
o Critical Discourse Analysis
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 4
SQUARE - Step 6: Elicit Security
Requirements
heart of the SQUARE process
• Goal: elicit correct requirements
• Content: execute the selected elicitation technique and elicit easy-to-verify
requirements
• Mistakes in this step
o elicit non-verifiable or vague, ambiguous requirements
o elicit implementations or architectural constraints instead of requirements
Verifiable?
“The system shall improve the availability of the existing customer
service center.”
Constraints?
“The system shall use SSH to complete the communication system.”
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 4
SQUARE - Step 7: Categorize
Requirements
• Goal: prepare for prioritizing requirements
• Content: allow the requirements engineer and stakeholders to classify the
requirements as essential, non-essential, system level, software level, or
as architectural constraints
• should avoid producing architectural constraints
• need to identify constraints and remove them
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 4
SQUARE - Step 8: Prioritize
Requirements
• Goal: choose which requirements to implement and in what order
• Content: prioritize the security requirements using the risk assessment and
categorization results as a basis for decision making
• Why?:
o the client organization will be unable to implement all of the
security requirements due to lack of time, resources, or developing
changes in the goals of the project.
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 4
SQUARE - Step 9: Requirements
Inspection
• Goal: find any defects in the requirements such as ambiguities,
inconsistencies, or mistaken assumptions
• Content: create a set of accurate and verifiable security requirements
Example Inspection Checklist
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 4
What are the three core security properties
we have mentioned?
Core Security Properties – Also
• Requirements
Confidentiality – The system must not disclose any
information intended to be hidden
E.g. your credit card information on a website
• Integrity – A system must not allow assets to be
subverted
by unauthorized users, e.g., changing someone’s
date of birth
– We must be able to trust what is in a system
• The data being stored
• The functionality being executed
• Availability – A system must be able to be available and
operational to users, e.g., bringing down Amazon.com
– These are extremely hard to protect against
• Any system performance degradation that can be triggered by a user can
be used for denial of service attacks
• Concurrency issues, infinite loop, or resource exhaustion
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 4
Types of Security
Requirements
Source: SSDLC Stage One: Security Requirements, Farza, Iosentrix
University of 49
Adelaide
Types of Security Requirements
Functional Requirements Non-Functional Requirements
A non-functional requirement defines the quality attribute of a
A functional requirement defines a system or its component.
software system.
It places constraints on “How should the software system fulfill the
It specifies “What should the software system do?”
functional requirements?”
Non-functional requirement is specified by technical peoples e.g.
Functional requirement is specified by User.
Architect, Technical leaders and software developers.
It is mandatory. It is not mandatory.
It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a system as a whole.
Helps you verify the functionality of the software. Helps you to verify the performance of the software.
Functional Testing like System, Integration, End to End, API testing, Non-Functional Testing like Performance, Stress, Usability, Security
etc are done. testing, etc are done.
Usually easy to define. Usually more difficult to define.
Example
Example
1) Emails should be sent with a latency of no greater than 12 hours
1) Authentication of user whenever he/she logs into the system.
from such an activity.
2) System shutdown in case of a cyber attack.
2) The processing of each request should be done within 10 seconds
3) A Verification email is sent to user whenever he/she registers for
3) The site should load in 3 seconds when the number of
the first time on some software system.
simultaneous users are > 10,000
Source: Geeksforgeeks 50
Sample Security Requirements
Source: The importance of security requirements elicitation and how to do it, Silva et al., 2015
University of 51
Adelaide
Sample Security Requirements
Source: Requirements. James Walden Northern Kentucky University
University of 52
Adelaide
Sample Security Requirements
Source: Requirements. James Walden Northern Kentucky University
University of 53
Adelaide
What security requirement do you think
the system needs?
University of 54
Adelaide
Summary
• There are different ways to elicit
software
requirements
• Security requirements is one of the
most important part of requirements
engineering
• Requirements must be passed through
quality criteria before finalizing them
• Security requirements are collected
against each security goal
Source: Requirements. James Walden Northern Kentucky University
• Various examples of security
University of 55
Adelaide
References
1. “Security Quality Requirements Engineering
(SQUARE)”. Carnegie Mellon University. 2017
