Security › Module 3 › Lesson 2
Least Privilege Design
Requirements security literacy names abuse cases, security user stories, non-functional security requirements, and acceptance criteria — draft requirement rows on YOUR $ARCH_LAB before privacy by design.
Visual · t41_requirements_security
Requirements security literacy. $ARCH_LAB only. Original Cyberlium.
Opening
Functional specs without security requirements ship gaps — literacy teaches abuse-case vocabulary so fictional org features on $ARCH_LAB get testable security criteria.
Security requirements translate architecture principles into testable statements — authentication strength, session timeout, encryption in transit, audit logging, input validation boundaries. Abuse cases describe how an adversary might misuse YOUR fictional feature — for design review, not attack cookbook against live targets. Cyberlium writes requirement row on YOUR $ARCH_LAB — feature name, security requirement, abuse case, acceptance criterion for one LAB-ARCH-001 story. Next: Privacy by Design.
1. Requirements security components (named)
Security user story: as a defender I need MFA on admin console for LAB-ARCH-001. Non-functional requirement: TLS 1.2+ for all example.local API calls. Abuse case: credential stuffing on login — mitigated by rate limit. Acceptance criterion: failed login lockout after N attempts testable in QA.
On $ARCH_LAB, write requirement row — feature, security requirement, abuse case, acceptance test for one fictional story.
Command guide
Try these commands — Requirements security components (named)
═══ LINUX / macOS (Terminal Practice) ═══
Check system state and user context
Command — copy this
id whoami uname -a
Inspect network sockets listening for connections
Command — copy this
ss -tuln 2>/dev/null || netstat -tuln
Audit active processes
Command — copy this
ps aux | grep -v "\[" | head -15
═══ WINDOWS (POWERSHELL) ═══ Query user identity and system information
Command — copy this
whoami /all Get-ComputerInfo | Select-Object CsName, OsName, OsVersion
Primary tools to practice this lesson: grep, python3. Reference sites: Microsoft SDL (https://www.microsoft.com/en-us/securityengineering/sdl/); OWASP SAMM (https://owaspsamm.org/); NIST SSDF (https://csrc.nist.gov/publications/detail/sp/800-218/final). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.
2. Why testable requirements beat vague 'make it secure'
Auditors and QA need pass/fail criteria — 'encrypt data' fails without algorithm and scope. Abuse cases force designers to think like reviewers without drafting live attack plans. Version-controlled requirements survive sprint review on lab templates.
Students draft lab requirements on notes — production requirements follow product security and legal review.
3. Lab boundary
Forbidden: writing abuse cases as step-by-step attack cookbook against real domains. Allowed: requirements security card — testable criteria with $ARCH_LAB fictional placeholders.
Ship: requirement row for YOUR lab feature. Next: Privacy by Design.
4. What you ship: security requirement row for $ARCH_LAB
Feature, security requirement, abuse case, acceptance criterion. $ARCH_LAB named. chmod 600.
5. What you record before the next lesson
Date. Requirement row. $ARCH_LAB named. File t41-m03-l02-requirements-security.txt chmod 600.
6. Wrong vs right: offensive playbooks vs YOUR threat models
Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.
Wrong
Write 'secure the app' as only requirement. Draft live attack steps in abuse case.
Right
Write security requirement row for YOUR $ARCH_LAB fictional feature. Next: Privacy by Design.
Mission: draft security requirements on YOUR lab
1) Name one fictional LAB-ARCH-001 feature. 2) Write one security requirement and abuse case. 3) Add testable acceptance criterion. 4) chmod 600.
Stuck? Ask Cyberlium AI Mentor
Acceptance criteria must be testable — vague security adjectives fail QA.
Knowledge Check
APPLY: Requirements security on Cyberlium includes:
Multiple choice
Knowledge Check
APPLY: True or False: Abuse cases in lab describe misuse scenarios for design review — not live attack plans.
True or False
Knowledge Check
APPLY: Requirements security literacy on Cyberlium uses:
Multiple choice