SSE_T3_LEC3_2024.pptx asdasdasdasdasdada

Outlin
e
1
• Software requirements elicitation
• Quality criteria for requirements
• Software security requirements
• Security requirements examples

Software Requirement Engineering
3
Source: Requirements engineering by Dagmar Monett – Berlin School of
Economics and Law

Software Requirements Elicitation
4
Economics and Law

Software Requirements Elicitation
5
Economics and Law

Software
Stakeholder
6
Economics and Law

Software Customer
7
Economics and Law
[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.”

Requirements Elicitation Techniques
8
Source: Top 5 Requirements Elicitation Techniques for Business Analysts, Techcanvass

Interviews
9
Economics and Law

Workshops
10
Economics and Law

Observations
11
Economics and Law
University of Adelaide

Brainstorming/focus group
12
Economics and Law

Document Analysis
13
Economics and Law
most commonly used/easiest method to collect software requirements

Quality criteria for requirements
14
Economics and Law

15
Economics and Law

16
Economics and Law

17
Economics and Law

18
Economics and Law

19
Economics and Law

20
Economics and Law

21
Economics and Law

22
Economics and Law

23
Economics and Law

24
Economics and Law

25
Economics and Law

26
Economics and Law

Security Quality Requirements Engineering
These slides contain material sourced (verbatim and/or modified) from the references provided at end of this
presentation. 27
• 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

SQUARE – Some Details
presentation. 28
• 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

SQUARE Steps
presentation. 29
• 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.

SQUARE Steps
presentation. 30
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 satisfies the
security goals of the project, contains clear and verifiable requirements, and is agreed
on by all relevant stakeholders.

Different Aspects of SQUARE Steps
presentation. 31
Step Name Input Techniques Participants/Outputs
Agree on definitions Candidate definitions
from IEEE and other
standards
Structured
interviews, focus
group
Stakeholders,
requirements
engineer/Agreed-to-
definitions
Identify assets and
security goals
Definitions, candidate
goals, business
drivers, policies and
procedures
Facilitated work
session, surveys,
interviews
Stakeholders,
requirements engineer/
Assets and goals
Develop artifacts to
support security
requirements
definition
Potential artifacts
(e.g., scenarios,
misuse cases,
templates, forms)
Work session Requirements
engineer/ Scenarios,
misuse cases, models,
templates, forms
Perform risk assessment Misuse cases,
scenarios, security
goals
Risk assessment
method, analysis of
anticipated risk against
organizational risk
tolerance, threat
analysis
Requirements engineer
& expert stakeholders/
risk assessments
results
Select
elicitation
techniques
Goals, definitions,
candidate techniques,
expertise of
stakeholders,
organizational style,
culture, level of
security needed,
cost/benefit
Work session Requirements
engineers/ Selected
elicitation techniques

Different Aspects of SQUARE Steps
presentation. 32
Step Name Input Techniques Participants/Outputs
Elicit security
requirements
Artifacts, risk
assessment results,
selected techniques
Application
Development (JAD),
interviews, surveys,
model-based analysis,
checklists, lists of
reusable requirements
types, document
reviews
Stakeholders facilitated
by requirements
engineer/Initial cut at
security requirements
Categorize requirements
as to level (system,
software, etc.) and
whether they are
requirements or other
kinds of constraints
Initial
requirements,
architecture
Work session using a
standard set of
categories
Requirements
engineer, other
specialists as
needed/Categorized
requirements
Prioritize requirements Categorized
requirements and risk
assessment results
Prioritization methods
such as Analytical
Hierarchy Process
(AHP), Triage, Win- Win
Stakeholders facilitated
by requirements
engineer/ Prioritized
requirements
Inspect requirements Prioritized
requirements,
candidate formal
inspection technique
Inspection method such
as Fagan, peer reviews
Inspection team/Initial
selected requirements,
documentation of
decision- making
process and rationale

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.
presentation. 33

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
presentation. 34

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;
presentation. 35

presentation.
Example system architecture diagram
36

presentation.
Example Attack Tree
 An attacker’s goal is listed as the root node;
 Tree leaves represent different ways to achieve that goal
37

presentation.
Sample Use Case Diagram
38

Example of misuse
Source: Sindre, G. and Opdahl, A. L., 2005
39

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
presentation.
Example risk assessment
40

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
presentation. 41

SQUARE - Step 6: Elicit Security Requirements
• 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
presentation.
 heart of the SQUARE process
 Verifiable?
“The system shall improve the availability of the existing customer
service center.”
 Constraints?
“The system shall use SSH to complete the communication system.”
42

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
presentation.
• should avoid producing architectural constraints
• need to identify constraints and remove them
43

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.
presentation. 44

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
presentation.
Example Inspection Checklist
45

What are the three core security properties
we have mentioned?

Core Security Properties – Also
Requirements
presentation. 47
• 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

Types of Security Requirements
48
Source: SSDLC Stage One: Security Requirements, Farza, Iosentrix

Types of Security Requirements
49
Functional Requirements Non-Functional Requirements
A functional requirement defines a system or its component.
A non-functional requirement defines the quality attribute of a
software system.
It specifies “What should the software system do?”
It places constraints on “How should the software system fulfill the
functional requirements?”
Functional requirement is specified by User.
Non-functional requirement is specified by technical peoples e.g.
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,
etc are done.
Non-Functional Testing like Performance, Stress, Usability, Security
testing, etc are done.
Usually easy to define. Usually more difficult to define.
Example
1) Authentication of user whenever he/she logs into the system.
2) System shutdown in case of a cyber attack.
3) A Verification email is sent to user whenever he/she registers for
the first time on some software system.
Example
1) Emails should be sent with a latency of no greater than 12 hours
from such an activity.
2) The processing of each request should be done within 10 seconds
3) The site should load in 3 seconds when the number of
simultaneous users are > 10,000
Source: Geeksforgeeks

Sample Security Requirements
50
Source: The importance of security requirements elicitation and how to do it, Silva et al., 2015

51
Source: Requirements. James Walden Northern Kentucky University

52

What security requirement do you think
the system needs?
53

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
• Various examples of security requirements
54

References
1. “Security Quality Requirements Engineering (SQUARE)”.
Carnegie Mellon University. 2017

SSE_T3_LEC3_2024.pptx asdasdasdasdasdada

More Related Content

Similar to SSE_T3_LEC3_2024.pptx asdasdasdasdasdada (20)

Recently uploaded (20)

SSE_T3_LEC3_2024.pptx asdasdasdasdasdada

Editor's Notes