Certified Secure Software Lifecycle Professional (CSSLP) — Lesson 2: Security Requirements, Privacy, Abuse Cases, Architecture, and Threat Modeling

Learning Objectives

• Distinguish the roles, assumptions, and evidence associated with security requirements, privacy requirements, and misuse and abuse cases.
• Apply secure architecture and threat modeling while completing a controlled derive testable requirements and model threats for a sensitive customer-facing service.
• Defend a decision about which requirements and architecture changes most effectively reduce material exposure using risk, operational, and governance considerations.

Detailed Topics

• Challenge security requirements with a realistic misuse, failure, or change condition before accepting the result.
• Document privacy requirements with ownership, evidence, review criteria, and a clear next action.
• Trace misuse and abuse cases from business need to technical implementation and retained assurance evidence.
• Evaluate secure architecture against policy, risk appetite, architecture constraints, and measurable acceptance criteria.
• Use threat modeling to resolve a course-specific decision and record why rejected options were not selected.

Instructor Demonstration

A guided demonstration traces the scenario from initial evidence to an approved conclusion. Learners observe how derive testable requirements and model threats for a sensitive customer-facing service, how competing options are ruled out, and how the requirements traceability matrix and threat model records the final rationale.

Hands-On Exercise

Use the course scenario to derive testable requirements and model threats for a sensitive customer-facing service, then submit a reviewable requirements traceability matrix and threat model.

1. Inventory the facts, assets, stakeholders, constraints, and evidence relevant to security requirements.
2. Perform the core analysis for privacy requirements and misuse and abuse cases, recording assumptions and rejected options.
3. Introduce the adverse condition where functional requirements are complete while privacy, abuse paths, and third-party trust assumptions remain implicit and revise the proposed response.
4. Complete the requirements traceability matrix and threat model with ownership, acceptance criteria, residual concerns, and the next review date.

Scenario Analysis

• Identify which assumption has the greatest effect on which requirements and architecture changes most effectively reduce material exposure.
• Compare two viable approaches involving secure architecture and explain their security and operational trade-offs.
• Specify the evidence required before the requirements traceability matrix and threat model can be accepted.

Troubleshooting Guidance

Separate symptoms from causes by tracing the decision back through inputs, trust assumptions, implementation evidence, and stakeholder responsibilities. Do not close the issue until the scenario in which functional requirements are complete while privacy, abuse paths, and third-party trust assumptions remain implicit has been reproduced or ruled out.

Validation Checklist

• The scope and ownership for security requirements are explicit and agreed.
• The selected treatment for privacy requirements is supported by scenario evidence rather than assumption.
• The exception involving functional requirements are complete while privacy, abuse paths, and third-party trust assumptions remain implicit was tested and its impact was recorded.
• The requirements traceability matrix and threat model identifies acceptance criteria, residual risk, responsible owners, and follow-up actions.

Lesson Outcome

Learners can apply Security Requirements, Privacy, Abuse Cases, Architecture, and Threat Modeling, explain which requirements and architecture changes most effectively reduce material exposure, and support the conclusion with a reviewable requirements traceability matrix and threat model.