Functional Security Requirements and Use Cases

Why This Topic Matters
The Secure Software Requirements domain of the CSSLP exists because most security defects are not coding mistakes – they are missing or vague requirements. If no one ever wrote down that a password reset link must expire in 15 minutes, no developer will build it and no tester will test it. Functional security requirements and use cases are the mechanism by which security gets written into the software from the very beginning, when it is cheapest to get right. The CSSLP repeatedly emphasizes that fixing a defect in requirements costs a fraction of fixing it in production, so the exam expects you to know how security is expressed as a requirement, how use cases (and their dark twins, misuse and abuse cases) are built, and how requirements are traced through the rest of the lifecycle.

What Are Functional Security Requirements?
A functional requirement describes what the system must do – a behavior that can be observed, invoked and tested. A functional security requirement is a functional requirement whose purpose is to protect the confidentiality, integrity or availability of the system and its data. Contrast this with non-functional (quality) requirements, which describe how well the system behaves (performance, scalability, maintainability, usability). Many security requirements are functional because they describe concrete, testable behavior, but some (for example, 'the system shall be resilient to denial of service') lean toward the non-functional side. The exam likes to test whether you can tell the two apart.

Core Categories of Functional Security Requirements
The CSSLP body of knowledge organizes security functionality around the security goals and the AAA controls. You should be able to recognize examples of each:

1. Confidentiality requirements – protecting data from unauthorized disclosure. Examples: data at rest encrypted with AES-256; data in transit protected with TLS 1.2 or higher; credit card numbers masked except the last four digits; sensitive data not written to logs.

2. Integrity requirements – ensuring data and code are not altered improperly. Examples: input validation against an allow-list; hashing or digital signatures to verify files; referential integrity in the database; code signing for deployed binaries; use of checksums on transmitted messages.

3. Availability requirements – ensuring the system is usable when needed. Examples: 99.9 percent uptime, Maximum Tolerable Downtime (MTD), Recovery Time Objective (RTO), Recovery Point Objective (RPO), rate limiting, graceful degradation, failover and load balancing.

4. Authentication requirements – verifying claimed identity. Examples: multi-factor authentication for administrative accounts; password complexity and length; account lockout after a defined number of failed attempts; secure credential storage using salted adaptive hashing; support for federated identity (SAML, OpenID Connect).

5. Authorization requirements – deciding what an authenticated identity may do. Examples: role-based access control (RBAC), attribute-based access control (ABAC), least privilege, separation of duties, deny-by-default, complete mediation of every access request, and a subject-object matrix that maps who may do what to which resource.

6. Accountability (auditing and logging) requirements – making actions traceable to an identity. Examples: logging of who, what, when and where for security-relevant events; log integrity protection; time synchronization; log retention periods; non-repudiation via digital signatures.

7. Session management requirements – examples: session tokens that are random and unpredictable; absolute and idle timeouts; regenerating the session ID after login; secure and HttpOnly cookie flags.

8. Error and exception handling requirements – examples: generic error messages to users, detailed errors only in secured logs, fail-secure behavior.

9. Configuration and change management requirements – examples: secure defaults, removal of sample files and default accounts, hardened baselines, controlled change process.

10. Data classification and privacy requirements – examples: labeling data as public, internal, confidential or restricted; handling rules per classification; data retention and disposal; privacy requirements driven by GDPR, HIPAA, PCI DSS, etc.

Where Security Requirements Come From
Elicitation is the act of discovering requirements. The CSSLP identifies several sources:
• Internal: organizational security policies, standards, guidelines, data classification schemes, business objectives and stakeholder interviews.
• External: laws and regulations, industry standards (PCI DSS, ISO 27001, NIST), contractual obligations, customer demands.
• Techniques: brainstorming, surveys and questionnaires, policy decomposition (breaking high-level policy statements down into specific, implementable requirements), data classification exercises, subject-object matrices, and use case / misuse case modeling.

Characteristics of a Good Security Requirement
A requirement must be unambiguous, complete, consistent, testable (verifiable) and traceable. Many instructors apply the SMART mnemonic: Specific, Measurable, Achievable, Relevant, Time-bound. 'The system shall be secure' is a poor requirement. 'The system shall lock a user account for 30 minutes after five consecutive failed login attempts within 10 minutes, and shall log each lockout event' is a good one – a tester can verify it exactly.

Use Cases: Describing Intended Behavior
A use case describes how an actor (a user, another system or a role) interacts with the system to achieve a goal. Use cases originate in UML and typically contain:
• Actor(s) – who initiates or participates.
• Preconditions – what must be true before the use case starts (e.g., user is authenticated).
• Main (basic) flow – the normal, happy-path sequence of steps.
• Alternate flows – legitimate variations.
• Exception flows – what happens when things go wrong (invalid input, timeout).
• Postconditions – the state of the system when the use case ends.

Use cases are valuable for security because they force the team to think through every step, including preconditions (which translate to authentication and authorization checks) and exception flows (which translate to error handling and fail-secure requirements). However, use cases describe what the system should do – they say little about what an attacker might do. That gap is filled by misuse and abuse cases.

Misuse Cases and Abuse Cases: Describing Unintended Behavior
A misuse case is a use case from the point of view of a hostile actor (the mis-actor or misuser). It describes a sequence of actions that would cause harm if allowed. Misuse cases are typically drawn in the same diagram as use cases, often shown as shaded or inverted ovals, with special relationships:
• threatens – the misuse case threatens a legitimate use case (e.g., 'Steal credentials' threatens 'Log in').
• mitigates – a security use case mitigates a misuse case (e.g., 'Enforce MFA' mitigates 'Steal credentials').

Each mitigating security use case becomes a functional security requirement. This is the key linkage the exam tests: use case → misuse case → mitigation → security requirement.

The terms misuse case and abuse case are often used interchangeably. Where a distinction is drawn, a misuse case may include unintentional harm (a careless user) while an abuse case emphasizes deliberate malicious intent. For exam purposes, treat both as techniques to model what an attacker would do, and as a bridge between requirements and threat modeling.

How the Process Works End to End
1. Identify actors and assets – who uses the system and what data or functions need protecting (data classification feeds this).
2. Write use cases for each business goal, including preconditions and exception flows.
3. Derive misuse cases by asking, for each use case, how an attacker could subvert, bypass or abuse it. Use STRIDE categories (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) as prompts.
4. Define mitigations as security use cases and convert them into specific, testable functional security requirements.
5. Build a subject-object matrix to capture authorization requirements precisely.
5. Capture non-functional security requirements too (availability targets, performance under attack load).
6. Record everything in a Requirements Traceability Matrix (RTM). The RTM links each requirement to its source (policy, regulation, misuse case), to the design element that implements it, to the code, and to the test case that verifies it. Traceability is how you prove that no requirement was dropped and that every control is tested.
7. Validate with stakeholders and baseline the requirements under change control.

Common Pitfalls
• Writing security requirements as vague statements ('must be secure', 'must be hack-proof').
• Treating security purely as non-functional and leaving it out of use cases.
• Only modeling happy paths and ignoring exception and misuse paths.
• Failing to trace requirements to tests, so controls are never verified.
• Gathering requirements once and never revisiting them as threats or regulations change.

Exam Tips: Answering Questions on Functional Security Requirements and Use Cases

Tip 1 – Know functional versus non-functional. If the question describes an observable, testable behavior (encrypt, authenticate, log, lock out, validate), it is functional. If it describes a quality attribute (how fast, how available, how maintainable), it is non-functional. Availability percentages, RTO and RPO are generally classified as non-functional even though they are security-related.

Tip 2 – Map examples to categories instantly. Expect scenario questions such as 'A requirement states that all administrative actions must be recorded with user ID and timestamp. Which security requirement category is this?' The answer is accountability (auditing/non-repudiation), not integrity or authentication. Practice sorting examples into confidentiality, integrity, availability, authentication, authorization, accountability, session management, error handling and configuration management.

Tip 3 – Use cases describe intended behavior; misuse cases describe hostile behavior. If the question asks which technique helps identify how an attacker could subvert functionality during requirements gathering, the answer is misuse (or abuse) cases, not use cases, data flow diagrams or code review. If it asks which technique documents the normal interaction between an actor and the system, the answer is use cases.

Tip 4 – Remember the relationships. A misuse case threatens a use case; a security use case mitigates a misuse case. The actor in a misuse case is a mis-actor or misuser. These vocabulary questions are quick points.

Tip 5 – The best requirement is the testable one. When asked to pick the best-written security requirement, eliminate anything vague or unmeasurable and choose the option with specific numbers, mechanisms and conditions. Also prefer requirements that are implementation-independent where appropriate (what, not how), unless the question is specifically about a design constraint.

Tip 6 – Traceability is the answer to 'how do we prove it was done'. Questions about ensuring every security requirement is implemented and tested, or about assessing the impact of a changed requirement, point to the Requirements Traceability Matrix.

Tip 7 – Think about sources of requirements. When a scenario mentions regulations, contracts or industry standards, the requirement source is external. When it mentions company policy or data classification, the source is internal. Policy decomposition is the technique for turning high-level policy into granular requirements.

Tip 8 – Authorization questions often hint at the subject-object matrix. If the scenario is about documenting which roles can perform which operations on which resources, the subject-object matrix (sometimes called an access control matrix) is the tool.

Tip 9 – Earliest is cheapest. If asked where in the SDLC security requirements should be defined, or why requirements-phase security matters, the exam wants the answer that emphasizes defining requirements at the beginning because defects are least costly to fix there.

Tip 10 – Watch for distractors from later phases. Threat modeling, attack surface analysis, static code analysis and penetration testing are legitimate security activities, but when the question is explicitly about the requirements phase, choose the requirements-phase technique (use cases, misuse cases, data classification, subject-object matrix, RTM). Misuse cases are the bridge: they are performed during requirements and feed into threat modeling during design.

Tip 11 – Read for the keyword 'MOST' or 'BEST'. Many CSSLP questions have several plausible answers. Pick the one that is most specific to the requirements phase, most aligned with testability and traceability, and most directly addresses the security goal named in the stem.

Quick Review Summary
• Functional security requirements describe testable security behavior; non-functional ones describe quality attributes.
• Categories: confidentiality, integrity, availability, authentication, authorization, accountability, session management, error handling, configuration management, data classification and privacy.
• Use cases model legitimate actor-system interaction with preconditions, flows and postconditions.
• Misuse and abuse cases model hostile actors; they threaten use cases and are mitigated by security use cases that become requirements.
• Good requirements are specific, measurable, achievable, relevant, time-bound, unambiguous and traceable.
• The Requirements Traceability Matrix links requirements to sources, design, code and tests.
• Security requirements defined early are the cheapest and most effective security investment in the SDLC.