UNIT – II SECURE SOFTWARE DESIGN

Requirements Engineering for secure software - SQUARE process Model – Requirements

elicitation and prioritization - Isolating the Effects of Untrusted Executable Content – Stack
Inspection – Policy Specification Languages – Vulnerability Trends – Buffer Overflow – Code
Injection – Session Hijacking. Secure Design - Threat Modeling and Security Design Principles

REQUIREMENT ENGINEERING
Definition: Systematic process of gathering, analyzing, documenting, validating, and managing
requirements.

Objective: Deliver software that satisfies business goals and user expectations.

Key Steps

a. Elicitation – Collect requirements from stakeholders.

b. Analysis – Resolve conflicts, check feasibility, prioritize.
c. Specification – Document clearly (SRS).
d. Validation – Confirm correctness with users.
e. Management – Handle changes & maintain traceability.

1. Requirement Elicitation Techniques

 Interviews, surveys, observation, prototyping, brainstorming, workshops.

 Challenges: Communication gaps, ambiguity, conflicting needs.

2. Types of Requirements

 Functional Requirements (FRs): Define system operations and behaviors.

 Non-Functional Requirements (NFRs): Define qualities like performance, usability,
reliability, security.
 Domain Requirements: Industry-specific rules and standards.

3. Software Requirement Specification (SRS)

 Acts as a contract between client & developer.

 Should be correct, complete, consistent, verifiable, modifiable, and traceable.

Structure of SRS

 Introduction – Purpose, scope, definitions.

 Overall Description – System perspective, user needs.
 Specific Requirements – Functional & non-functional.
  External Interfaces – Hardware, software, communication.
 Appendices – Glossary, references.

4. Requirement Validation

 Ensures requirements are correct & feasible.

 Methods: Reviews, inspections, prototyping, test-case derivation.

5. Requirement Management

 Important because requirements evolve.

 Involves:
o Version control
o Change control
o Traceability (linking requirements → design → implementation → testing)
o Impact analysis

Importance of Requirements Engineering

 Prevents misunderstandings between users and developers.
 Reduces cost by avoiding rework.
 Provides a strong foundation for all later stages of the SDLC.
 Ensures the system meets both functional goals and quality expectations.

Conclusion
 Requirements form the backbone of software engineering.
 A clear, validated, and well-managed requirements process ensures project success.
 The SRS (Software Requirements Specification) document is the key deliverable that
guides design, coding, and testing.

Note
Functional Requirements

Define what the system should do (features, services, behaviors). They describe the
functionality from the user's perspective.

Examples:

 User login and authentication.

 Processing payments.
  Sending email notifications.
 Role-Based Access Control (RBAC).
 Searching and retrieving data.

Non-Functional Requirements (NFRs)

Define how the system should perform (quality attributes, constraints, standards). They ensure
the system is usable, reliable, secure, and efficient.

Examples:

 Performance: System must handle 10,000 users simultaneously.

 Security: Data must be encrypted in transit and at rest.
 Availability: 99.99% uptime guaranteed.
 Usability: Interface should be accessible (e.g., WCAG standards).
 Scalability: Must support future growth in users/transactions.
 Compliance: Meet regulations like GDPR or HIPAA.

Key Difference

 Functional = WHAT the system does (features).

 Non-functional = HOW well it does it (qualities/constraints).

Example (Online Banking App):

 Functional: Users can transfer money between accounts.

 Non-functional: The transfer must complete in < 2 seconds and be logged for auditing.

SQUARE Process Model

SQUARE (Security Quality Requirements Engineering) is a systematic method used in
software engineering to identify and manage security requirements early in the Software
Development Life Cycle (SDLC).

Goal: Reduce security risks, ensure software is reliable, and integrate security into project
requirements from the beginning.

1. Importance of Security Requirements

 Security is often neglected during requirement phases, leading to vulnerabilities.
 Well-defined security requirements:
o Reduce design flaws
o Improve system trustworthiness
o Lower long-term maintenance costs
2. SQUARE Methodology
The SQUARE process is divided into 9 steps:

1. Agree on Definitions – Establish common security terminology.

2. Identify Security Goals – Define high-level security objectives (e.g., confidentiality,
integrity, availability).
3. Develop Artifacts – Create supporting documents like system models, assumptions, and
constraints.
4. Perform Risk Assessment – Identify threats, vulnerabilities, and risks.
5. Select Elicitation Techniques – Choose methods (interviews, workshops, scenarios) to
gather security needs.
6. Elicit Security Requirements – Collect requirements from stakeholders.
7. Categorize Requirements – Functional, non-functional, and assurance requirements.
8. Prioritize Requirements – Rank based on risk, feasibility, and business value.
9. Inspect Requirements – Validate, refine, and finalize requirements for inclusion in the
SRS.

4. Benefits of SQUARE
 Integrates security early in the Software Development Life Cycle (SDLC).
 Helps avoid costly fixes later.
 Encourages collaboration between stakeholders and developers.
 Produces structured, traceable security requirements.

5. SQUARE Useful in Critical Domains Like

 Banking & Finance (fraud prevention)
 Healthcare (data privacy)
 Defense (secure communication)
 E-commerce (transaction safety)

Conclusion
 SQUARE is a structured framework that embeds security into requirements
engineering, helping organizations identify, prioritize, and validate security requirements
early in the software development process.

 By following its 9-step process, organizations can build secure, cost-effective, and
trustworthy systems.
 It ensures that security is not an afterthought but a core part of software development.
REQUIREMENTS ELICITATION AND
PRIORITIZATION
Importance of Requirements Elicitation & Prioritization
(Secure Software Design)
 Ensures the system meets stakeholder needs and security requirements.
 Focuses development on the most critical aspects.
 Security adds extra complexity (risks, compliance, vulnerabilities).

Requirements Elicitation
Definition:
The process of gathering and defining what stakeholders need from the system, including
functional, non-functional, and security requirements.

Key Steps

 Identify stakeholders: End-users, business owners, security experts, regulators, and

developers.
 Interviews & workshops: One-on-one interviews, focus groups, and brainstorming
sessions.
 Review existing sources: System documentation, regulations (GDPR, HIPAA), security
policies, and audit logs.
 Use cases & user stories: Cover both functionality and security (authentication,
authorization, data protection).
 Threat modeling: Identify possible attacks (SQL injection, XSS, privilege escalation).
 Prototyping & validation: Confirm requirements with stakeholders before design.

Eliciting Security Requirements

 Define security goals: Confidentiality, Integrity, and Availability (CIA).
 Identify critical assets (e.g., sensitive data, intellectual property).
 Assess threats and vulnerabilities (insider threats, DoS attacks, unauthorized access).
 Clarify compliance requirements (GDPR, PCI-DSS, HIPAA).
 Set non-functional security requirements (uptime, resilience under attack).

Requirements Prioritization
Definition:
Deciding which requirements are most important and must be implemented first.
Criteria for Prioritization

 Risk: Higher risk = Higher priority.

 Business Value: Impact on business success and goals.
 Compliance: Legal and industry requirements must be met.
 System Impact: Effect on architecture, performance, and user experience (UX).
 Cost: Time, resources, and trade-offs involved.

Techniques
MoSCoW Method

 Must Have: Essential requirements (e.g., Multi-Factor Authentication (MFA),

encryption, Role-Based Access Control (RBAC), compliance).
 Should Have: Important but not critical requirements (e.g., audit logging, session
management).
 Could Have: Nice-to-have features (e.g., advanced admin logging, UI security cues).

 Won't Have: Out of scope (e.g., behavioral biometrics).

 Risk-based Prioritization: Score requirements based on Likelihood × Impact.
 Risk Matrix & Cost-Benefit Analysis: Evaluate risks against implementation cost and
business value.

Other Considerations
 Incorporate stakeholder feedback.
 Meet compliance deadlines.
 Factor in threat models and risk assessments.

Summary
 Elicitation: Gather and define stakeholder and security requirements.
 Prioritization: Rank requirements based on risk, value, compliance, and cost.
 Together, they ensure secure, compliant, and effective software design.
ISOLATING THE EFFECTS OF
UNTRUSTED EXECUTABLE CONTENT
Secure software engineering relies on security isolation techniques (e.g., sandboxing) to build
robust and resilient software.

Isolating untrusted executable content is a core method used to prevent malicious or

vulnerable code from affecting the broader system. Quarantining suspicious code helps
maintain system functionality and protect against threats.

Definition:
A security technique that runs untrusted code in a restricted, controlled environment to prevent
it from interacting with or modifying sensitive parts of the system.

Untrusted executables (e.g., user uploads, third-party code, external services) can introduce risks
such as:

 Remote Code Execution (RCE)

 Data Leakage
 Privilege Escalation

Goal: Contain potential damage and prevent unauthorized access, even if malicious code is
executed.

Techniques & Approaches

1. Sandboxing

 Run untrusted code in isolated environments.

 Methods:
o OS Sandboxing (chroot, Windows Sandbox)
o Virtual Machines (VMs)
o Containers (Docker)
o Browser Sandboxes

2. Code Execution Limitations (Least Privilege)

 Restrict permissions so executables only do what is necessary.

 Tools:
o System call filtering (seccomp)
o SELinux
o Access Control Lists (ACLs)
o Non-privileged users
 o Dropping unnecessary capabilities

3. Memory Isolation & Control

 Protect against memory exploits.

 Techniques:
o ASLR (Address Space Layout Randomization)
o DEP/NX (blocks code execution in unsafe memory)
o CFI (Control Flow Integrity) – enforces valid execution flow

4. Code Review & Static Analysis

 Detect flaws before execution.

 Use static analysis tools such as:
o Clang
o Coverity
o SonarQube
 Perform manual code audits.

5. Runtime Application Self-Protection (RASP)

 Built-in runtime defenses.

 Features:
o Behavioral monitoring
o Taint analysis
o Intrusion detection

6. Network Isolation & Access Control

6. Network Isolation & Access Control

 Control external connections.
 Tools:
o Firewalls
o VPNs
o API gateways with authentication and rate limits

7. File & Data Handling

 Safely process untrusted files.
 Techniques:
o File type validation
o Sandboxing files
o Content Disarm and Reconstruction (CDR)
Techniques for Isolating Untrusted Executable Content

Technique /
Purpose How It Works Examples / Tools Protection Scope
Approach
chroot, Windows
Run applications Sandbox, Docker, Prevents malicious
Isolate untrusted
Sandboxing in controlled Virtual Machines code from escaping
code
environments (VMs), Browser into the host system
Sandboxes
Code Execution Reduces attacker
Restrict seccomp, SELinux,
Limitations Minimize damage control even if the
application AppArmor, ACLs,
(Least potential application is
permissions Non-privileged users
Privilege) compromised
Defends against
Memory Protect memory
Prevent memory buffer overflow,
Isolation & layout and ASLR, DEP/NX, CFI
exploits code injection,
Control execution
ROP/JOP attacks
Scan and audit Clang Analyzer,
Code Review & Stops vulnerabilities
Detect flaws early code before Coverity, SonarQube,
Static Analysis before deployment
execution Manual audits
Runtime Monitor Blocks attacks
Taint analysis,
Application Real-time runtime application during execution
Intrusion detection,
Self-Protection defense behavior (e.g., injection,
Anomaly monitoring
(RASP) internally abnormal behavior)
Technique /
Purpose How It Works Examples / Tools Protection Scope
Approach
Prevents
Network Restrict and Firewalls, VPNs, API
Control unauthorized data
Isolation & monitor network Gateways, Rate-
communications exfiltration or lateral
Access Control traffic limiting
movement
File type validation, Prevents malware,
Validate,
File & Data Safely process File Sandboxing, malicious payloads,
sanitize, and
Handling untrusted files Content Disarm and or injections through
rebuild data
Reconstruction (CDR) files

Conclusion

Isolating untrusted executables involves combining sandboxing, least privilege, memory

protection, code review, runtime defenses, network controls, and safe file handling to
minimize security risks and contain malicious activity.