1 of 27

SOFSEC1 – Software Security

Module 3: Softsec in the SDLC: Requirements & Design

Prof. Justin Pineda

Feb 2026

2 of 27

Pre-Work

Recall SDLC phases and prior OS security concepts

3 of 27

Learning Objectives

By the end of this session, students will be able to:

  • Explain security activities in the Requirements Phase
  • Balance customer wants, business objectives, and security needs
  • Apply basic threat modeling during the Design Phase

4 of 27

Motivation Question

“Why do many security vulnerabilities exist even before a single line of code is written?”

5 of 27

SDLC Refresher

6 of 27

Where Security Really Starts

Security starts at Requirements, not at Coding

7 of 27

Requirements Phase Explained

Functional requirements:

    • Login, transactions, reporting

Non-functional requirements:

    • Performance, availability, usability, security

Security usually belongs to non-functional requirements and is often overlooked

8 of 27

What Are Security Requirements?

Security requirements define protection expectations

  • Confidentiality: Who can see the data?
  • Integrity: Who can modify it?
  • Availability: How resilient must the system be?
  • Privacy & compliance: Laws, regulations, policies

9 of 27

Stakeholder Tension

Customer Wants vs Business Wants vs Security Needs

Customer:

  • Convenience, speed, minimal friction

Business:

  • Revenue, time-to-market, cost reduction

Security:

  • Controls, verification, monitoring, restrictions

Conflict is normal, not a failure.

10 of 27

Balancing the Triangle

Trade-offs are inevitable

  • Strong security may reduce usability
  • Strong usability may increase risk
  • Strong cost control may reduce protection

The goal is risk-informed balance, not “maximum security”

11 of 27

Examples of Security Requirements

Concrete, testable requirements

  • “Users must authenticate using MFA for admin access”
  • “Sensitive data must be encrypted at rest and in transit”
  • “All access must be logged and retained for 90 days”

Vague statements = weak security

12 of 27

Common Failures in Requirements

  • No security requirements documented
  • Assumptions like:
    • “It’s internal”
    • “No one will target this”
  • Security postponed to later phases → higher cost, weaker controls

13 of 27

Transition to Design Phase

Requirements shape architecture

Design translates requirements into:

  • Components
  • Data flows
  • Trust boundaries

Bad or missing security requirements → insecure architecture

14 of 27

Architectural Design Phase

High-level system structure

  • What talks to what?
  • Where data flows
  • Where trust starts and ends

Architecture defines attack surface

15 of 27

Why Architecture Matters for Security

Design choices define risk

  • Centralized vs distributed authentication
  • Direct database access vs API layer
  • Flat network vs segmented architecture

Fixing architecture later is extremely costly

16 of 27

Introduction to Threat Modeling

Design-time security analysis

Threat modeling asks:

  • What are we protecting?
  • Who might attack?
  • How could it be attacked?

Done before coding, not after breach

17 of 27

Core Threat Modeling Questions

Structured attacker thinking

  • What can go wrong?
  • How can it be exploited?
  • What is the impact?
  • What controls should exist?

18 of 27

STRIDE (High-Level)

  • Spoofing: pretending to be someone else
  • Tampering: unauthorized data changes
  • Repudiation: denial of actions
  • Information Disclosure: data leaks
  • Denial of Service: availability attacks
  • Elevation of Privilege: gaining higher access

19 of 27

Example: BigSky

User → Web App → Database

  • Where is authentication enforced?
  • Where does sensitive data flow?
  • What happens if one component is compromised?

Identify trust boundaries visually

20 of 27

Summary

  • Security starts in Requirements
  • Architecture determines attack surface
  • Threat modeling reduces surprises
  • Secure coding is ineffective without secure design

21 of 27

Knowledge Check 1

A fintech startup is building a mobile wallet application. During requirements gathering, the product owner states “Users should be able to log in quickly with minimal friction.”

No other security-related statements are documented. Two months later, the security team raises concerns about account takeover risks.

Which requirement should have been explicitly defined during the Requirements Phase to prevent this issue?

A. The application should be coded using a secure programming language

B. The application should authenticate users using multi-factor authentication for sensitive actions

C. The application should be penetration tested before deployment

D. The application should use the latest operating system version

22 of 27

Knowledge Check 2

An e-commerce company plans to remove CAPTCHA and login throttling to improve user experience during peak sales events. The security team warns this may increase credential stuffing attacks.

As a security-aware architect, what is the best response?

A. Reject the change entirely to prioritize security

B. Accept the change and rely on monitoring after deployment

C. Propose alternative controls that balance usability and security, such as adaptive risk-based authentication

D. Delay the project until a full security audit is completed

23 of 27

Knowledge Check 3

A development team designs a web application where the frontend directly connects to the database using embedded credentials to “reduce complexity.”

From a security design perspective, what is the primary risk introduced by this architecture?

A. Increased development effort

B. Larger application size

C. Expanded attack surface and lack of trust boundary enforcement

D. Reduced system availability

24 of 27

Knowledge Check 4

During the Design Phase, a team conducts threat modeling for a document management system. One identified scenario is:

“An attacker modifies stored documents without authorization.”

Which STRIDE threat category does this scenario fall under?

A. Spoofing

B. Tampering

C. Repudiation

D. Information Disclosure

25 of 27

Knowledge Check 5

A company discovers during penetration testing that sensitive customer data is transmitted in plaintext between internal services. Fixing this now requires major architectural changes.

What is the main lesson demonstrated by this scenario?

A. Penetration testing should be avoided in early releases

B. Security issues are unavoidable in complex systems

C. Security requirements and encryption decisions should be addressed during Requirements and Design phases

D. Developers should be trained more on secure coding

26 of 27

Key Takeaways

What design decision surprised you the most today

27 of 27

References

  • SOFSEC1 Course Syllabus
  • Recorded Lectures
  • Recommended Online Resources