Secure App 3
Here’s your Teaching Note, Quiz, and Answer Key for Section 3: Defining Security Requirements from the Fundamentals of Secure Application Development course.
🧑🏫 Teaching Note – Section 3: Defining Security Requirements
🎯 Learning Objectives
By the end of this section, students should be able to:
- Identify and define assets and threats relevant to a software project.
- Derive security requirements from use cases, misuse/abuse cases, and trust boundaries.
- Understand and categorize different types of security requirements.
- Understand the importance of traceability and expert review of security requirements.
🧭 Lesson Plan Outline (60 minutes)
1. Warm-up Recap: What Drives Security Requirements? (5 min)
- Review from Section 2: Security imperatives, risk appetite, organizational policies.
- Transition: Now we move from context to concrete security requirements.
2. Assets and Threats (10 min)
3. Misuse/Abuse Cases and Trust Boundaries (10 min)
- Explain misuse cases as “inverted use cases” from an attacker’s view.
- Teach trust boundaries in Data Flow Diagrams (DFDs).
- ✍️ Optional mini-exercise: Sketch a trust boundary crossing (e.g. user uploads a file).
4. Six Categories of Security Requirements (15 min)
Use concrete examples:
- Authentication
- Access Control
- Data Confidentiality
- Data Integrity
- Input Validation
- Monitoring & Logging
💡 Tip: Map examples to real apps students know (e.g., online banking, e-commerce).
5. Managing Requirements (10 min)
Emphasize:
- Traceability to vulnerabilities
- Review by domain experts
- Prioritization (not all security requirements are equally critical)
6. Wrap-up Discussion (10 min)
- When would a security requirement not be enforced?
- Who decides if a risk is worth accepting?
- Connect this to iterative/agile development – security isn't a one-time activity.
📝 Quiz – Section 3: Defining Security Requirements
🧠 Multiple Choice
What is the purpose of a misuse case?
A. To simplify user interfaces
B. To define security policies
C. To identify how a system might be attacked
D. To manage authentication settings
A trust boundary in a data flow diagram indicates:
A. Where data becomes encrypted
B. A change in user role
C. A point where untrusted data enters a trusted system
D. A point where an admin logs in
Which of the following is a data integrity requirement?
A. Logging all login attempts
B. Encrypting credit card details
C. Using checksums to detect data corruption
D. Limiting access to employee PII
What is input validation primarily used for?
A. Speeding up user submissions
B. Checking user roles
C. Detecting malformed or malicious inputs
D. Logging system performance
Which is a correct example of a monitoring and logging requirement?
A. Only Admins can update records
B. System must notify admin of 100+ failed logins in 10 minutes
C. Encrypt data in transit using TLS 1.3
D. Users must reset passwords every 30 days
✅ True/False
- ___ Every security requirement must trace to a known vulnerability or threat.
- ___ Use cases and misuse cases help identify needed security requirements.
- ___ Logging is a replacement for authentication.
- ___ Trust boundaries help identify risky data flows.
- ___ All security requirements should be treated as the highest priority.
✏️ Short Answer
- Name two types of security requirements. Provide an example of each.
- Why is input validation especially important for public-facing systems?
- How can a misuse case be used to improve system security?
- What does “traceability” mean in the context of security requirements?
- How would you determine which security requirements have the highest priority?
✅ Answer Key – Section 3 Quiz
Multiple Choice
- C
- C
- C
- C
- B
True/False
- True
- True
- False
- True
- False
Short Answer – Sample Answers
11.
- Authentication: Example – Require two-factor login for admin panel.
- Data Confidentiality: Example – Encrypt employee salary data at rest.
12.
Because inputs from users (especially over the internet) are untrusted and often exploited (e.g., SQL injection, XSS).
13.
By revealing how an attacker could exploit the system, we can write specific requirements to prevent or limit the impact.
14.
Traceability means linking each security requirement to the threat or vulnerability it is meant to mitigate.
15.
By evaluating the severity of potential impact, likelihood of exploit, and the organization’s risk appetite.