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)
═══ TOOLS & WEBSITES ═══ Browse / read these (authorized learning only — stay in YOUR lab / program scope)
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
═══ INSTALL ═══
Linux (Debian/Ubuntu):
Command — copy this
sudo apt install python3
macOS:
Command — copy this
brew install python3
Windows: Download https://python.org/downloads/
═══ LINUX / macOS ═══
Command — copy this
export ARCH_LAB=${ARCH_LAB:-$HOME/cyberlium-lab/t41-arch}
export ARCH_DESIGN=${ARCH_DESIGN:-$ARCH_LAB/LAB-ARCH-001/security-design}
cat > "$ARCH_DESIGN/secure-by-design-checklist.md" <<'EOF'
# Secure-by-Design Checklist — LAB-ARCH-001 (literacy)
- [ ] Threat model started before major feature (STRIDE worksheet stub)
- [ ] Trust boundaries documented on context diagram
- [ ] Secrets not embedded in source; use vault/KMS pattern (fictional)
- [ ] Input validation at every trust boundary crossing
- [ ] Logging + audit trail for security-relevant events
- [ ] Dependency/supply chain review gate in CI (literacy)
LAB SAMPLE — defensive design checklist — NOT production sign-off
EOFCommand — copy this
grep -E '\[ \]|LAB SAMPLE|Threat model' "$ARCH_DESIGN/secure-by-design-checklist.md"
python3 -c "print('Secure-by-design: checklist literacy for fictional SaaS — no bypass recipes')"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