Scenario practice questions

You are analyzing an application to prevent unauthorized API access. Which requirement elicitation technique is best suited to identify potential entry points that an attacker might exploit?

Trap 1: User Story Mapping

User story mapping organises functional requirements around user journeys, capturing intended behaviour rather than adversarial entry points. It is the right technique when prioritising a backlog or defining scope with stakeholders for a new feature release.

Trap 2: Compliance Gap Analysis

Compliance gap analysis measures controls against a framework's clauses, producing remediation findings rather than enumerating attack surfaces. It is the right technique when preparing for an audit or certification against standards such as ISO 27001 or PCI DSS.

Trap 3: Cost-Benefit Analysis

Cost-Benefit Analysis weighs the financial return of a security control against its expense, so it cannot enumerate API entry points or attacker-reachable surfaces. It is tempting because it genuinely supports risk-treatment prioritisation once threats are known, and would be the right choice when justifying spend on remediating an already-identified vulnerability.

A
User Story Mapping
Why it fails: User story mapping organises functional requirements around user journeys, capturing intended behaviour rather than adversarial entry points. It is the right technique when prioritising a backlog or defining scope with stakeholders for a new feature release.
B
Abuse Case Modeling
Abuse case modelling deliberately examines how an attacker would misuse functionality, exposing entry points such as unvalidated parameters and exposed endpoints. This satisfies the stem's goal of identifying exploitable API entry points, unlike use cases, which describe only intended legitimate behaviour.
C
Compliance Gap Analysis
Why it fails: Compliance gap analysis measures controls against a framework's clauses, producing remediation findings rather than enumerating attack surfaces. It is the right technique when preparing for an audit or certification against standards such as ISO 27001 or PCI DSS.
D
Cost-Benefit Analysis
Why it fails: Cost-Benefit Analysis weighs the financial return of a security control against its expense, so it cannot enumerate API entry points or attacker-reachable surfaces. It is tempting because it genuinely supports risk-treatment prioritisation once threats are known, and would be the right choice when justifying spend on remediating an already-identified vulnerability.

Question 2mediummultiple choice

Your organization is adopting the SLSA framework to improve supply chain security. You are evaluating a build system that claims to meet SLSA level 3. During an assessment, you find that the build system generates provenance but does not sign it, and the provenance is stored on the same server that performs builds. Which SLSA level requirement is most directly violated by this finding?

Trap 1: The build system must provide a software bill of materials (SBOM)…

SLSA does not require an SBOM as part of its levels. SBOMs are complementary but separate from SLSA's provenance requirements. The finding described concerns the integrity and signing of provenance, not the presence of an SBOM. Therefore, this is not the requirement that is violated. SBOM generation is often encouraged but not mandated by SLSA levels.

Trap 2: All build steps must be defined in a human-readable configuration…

While version-controlled build definitions are a good practice and part of SLSA level 2, they are not the specific requirement violated here. SLSA level 3 focuses on the integrity of the build platform and the provenance it generates. The lack of signing and separate storage is a more direct violation of level 3's tamper-resistance and non-falsifiability requirements.

Trap 3: The build system must be hosted by a third-party cloud provider and…

SLSA does not mandate a specific hosting location or provider. It requires that the build platform be hardened and that its integrity be verifiable, but this can be achieved on-premises with appropriate controls. The key is isolation, tamper resistance, and auditable processes, not whether the infrastructure is cloud-based or on-premises. Therefore, this finding does not directly violate a SLSA level 3 requirement.

A
The build system must provide a software bill of materials (SBOM) for every artifact it produces.
Why it fails: SLSA does not require an SBOM as part of its levels. SBOMs are complementary but separate from SLSA's provenance requirements. The finding described concerns the integrity and signing of provenance, not the presence of an SBOM. Therefore, this is not the requirement that is violated. SBOM generation is often encouraged but not mandated by SLSA levels.
B
All build steps must be defined in a human-readable configuration file that is version-controlled.
Why it fails: While version-controlled build definitions are a good practice and part of SLSA level 2, they are not the specific requirement violated here. SLSA level 3 focuses on the integrity of the build platform and the provenance it generates. The lack of signing and separate storage is a more direct violation of level 3's tamper-resistance and non-falsifiability requirements.
C
The build system must be hosted by a third-party cloud provider and not on-premises.
Why it fails: SLSA does not mandate a specific hosting location or provider. It requires that the build platform be hardened and that its integrity be verifiable, but this can be achieved on-premises with appropriate controls. The key is isolation, tamper resistance, and auditable processes, not whether the infrastructure is cloud-based or on-premises. Therefore, this finding does not directly violate a SLSA level 3 requirement.
D
The provenance must be signed by the build system and stored in a tamper-resistant location separate from the build infrastructure.
SLSA level 3 requires that provenance be generated by a trusted build platform and that it be signed and stored in a way that prevents tampering by the build system itself. Storing unsigned provenance on the same server allows an attacker who compromises the build server to alter both the artifact and its provenance. This violates the core requirement for non-falsifiable provenance and isolation between the build and provenance storage.

Question 3hardmulti select

Which TWO methods are effective for eliciting security requirements from non-technical business stakeholders?

Trap 1: Analyzing server log architecture

Server log architecture is a technical artefact that non-technical stakeholders cannot interpret, so it yields no elicited requirements from them. It is tempting because logs reveal real attack patterns, and would be the right input for technical threat modelling or incident analysis rather than business-facing requirements workshops.

Trap 2: Reviewing raw packet captures

Raw packet captures are low-level network data that non-technical stakeholders cannot read, so reviewing them elicits nothing from that audience. It is tempting because captures expose actual traffic and attacks, and would be correct for technical forensic investigation or intrusion analysis rather than business stakeholder requirements elicitation.

Trap 3: Reading the OWASP Top 10 documentation

Reading OWASP Top 10 documentation supplies a generic catalogue of technical weaknesses; it does not elicit stakeholder-specific needs from non-technical participants. It is tempting because it is an authoritative security reference, and would be correct for informing developers or testers about common vulnerability classes, not for gathering business requirements.

A
Presenting misuse case scenarios
Misuse case scenarios describe how an adversary could abuse a system, expressed in plain business language rather than technical controls. Non-technical stakeholders can reason about these narratives, surfacing security requirements they would struggle to articulate from abstract policy or configuration discussions.
B
Analyzing server log architecture
Why it fails: Server log architecture is a technical artefact that non-technical stakeholders cannot interpret, so it yields no elicited requirements from them. It is tempting because logs reveal real attack patterns, and would be the right input for technical threat modelling or incident analysis rather than business-facing requirements workshops.
C
Conducting risk impact workshops
Risk impact workshops translate threats into business consequences such as financial loss, regulatory exposure and operational downtime. Non-technical stakeholders can then articulate protection needs in familiar terms, satisfying the stem's requirement to elicit security requirements from them without relying on technical jargon.
D
Reviewing raw packet captures
Why it fails: Raw packet captures are low-level network data that non-technical stakeholders cannot read, so reviewing them elicits nothing from that audience. It is tempting because captures expose actual traffic and attacks, and would be correct for technical forensic investigation or intrusion analysis rather than business stakeholder requirements elicitation.
E
Reading the OWASP Top 10 documentation
Why it fails: Reading OWASP Top 10 documentation supplies a generic catalogue of technical weaknesses; it does not elicit stakeholder-specific needs from non-technical participants. It is tempting because it is an authoritative security reference, and would be correct for informing developers or testers about common vulnerability classes, not for gathering business requirements.

Question 4hardmultiple choice

You are eliciting security requirements for a new online banking application. The business stakeholders are focused on features and have limited security knowledge. You need to ensure that security requirements are complete, unambiguous, and testable. Which technique is MOST appropriate to achieve this?

Trap 1: Organize a focus group where stakeholders brainstorm all possible…

Brainstorming can generate ideas but often results in a wish list rather than well-defined requirements. Without a structured framework like misuse cases, stakeholders may propose vague or overlapping features. This approach risks missing critical threats and produces requirements that are difficult to test, as they may not be tied to specific abuse scenarios or acceptance criteria.

Trap 2: Interview the IT security team to document their existing security…

While existing policies provide a baseline, they are often high-level and not tailored to the specific application. Applying them directly can result in requirements that are not testable or may not address unique risks of the online banking app. Interviews with security alone may miss business context and stakeholder needs, leading to incomplete requirements.

Trap 3: Conduct a survey asking stakeholders to rate the importance of…

Surveys with predefined lists may yield quantitative data but do not help stakeholders articulate specific, context-relevant security requirements. They can lead to generic or incomplete requirements because stakeholders may not understand the controls or their applicability. This method lacks the depth needed to uncover nuanced threats and does not ensure requirements are testable or unambiguous.

A
Create misuse cases that describe how an attacker might abuse the system, and derive security requirements from them.
Misuse cases are a structured technique to identify negative scenarios and derive security requirements. They help non-technical stakeholders understand threats by illustrating attacker goals, making it easier to elicit specific, testable requirements. This approach directly addresses completeness and unambiguity by forcing consideration of abuse scenarios and corresponding mitigations, which can be validated during testing.
B
Organize a focus group where stakeholders brainstorm all possible security features they want in the application.
Why it fails: Brainstorming can generate ideas but often results in a wish list rather than well-defined requirements. Without a structured framework like misuse cases, stakeholders may propose vague or overlapping features. This approach risks missing critical threats and produces requirements that are difficult to test, as they may not be tied to specific abuse scenarios or acceptance criteria.
C
Interview the IT security team to document their existing security policies and apply them as requirements.
Why it fails: While existing policies provide a baseline, they are often high-level and not tailored to the specific application. Applying them directly can result in requirements that are not testable or may not address unique risks of the online banking app. Interviews with security alone may miss business context and stakeholder needs, leading to incomplete requirements.
D
Conduct a survey asking stakeholders to rate the importance of various security controls from a predefined list.
Why it fails: Surveys with predefined lists may yield quantitative data but do not help stakeholders articulate specific, context-relevant security requirements. They can lead to generic or incomplete requirements because stakeholders may not understand the controls or their applicability. This method lacks the depth needed to uncover nuanced threats and does not ensure requirements are testable or unambiguous.

Question 5mediummultiple choice

You are leading a threat modeling session for a new cloud-native application. You identify a potential threat where an attacker attempts to inject malicious SQL queries into the search bar. Which technique should you employ to document this behavior during the Secure Software Requirements phase?

Trap 1: Attack Tree Analysis

Attack Tree Analysis decomposes a goal such as SQL injection into sub-goals and conditions, which documents attacker behaviour rather than the requirement being elicited. It is tempting because it is a recognised threat-modelling technique, and would be correct during design threat enumeration, not the Secure Software Requirements phase.

Trap 2: Data Flow Diagramming

Data Flow Diagramming maps how data moves between processes, stores and external entities; it shows trust boundaries but not the attacker's step-by-step injection behaviour. It is tempting because DFDs underpin threat modelling, and would be correct when documenting system architecture and data movement rather than a specific attack path.

Trap 3: Compliance Matrix Mapping

Compliance Matrix Mapping traces requirements to controls or regulations; it records coverage, not the mechanics of an injection threat. It is tempting because it is used in requirements phases, and would be correct when demonstrating that each security requirement maps to a standard or control framework.

A
Attack Tree Analysis
Why it fails: Attack Tree Analysis decomposes a goal such as SQL injection into sub-goals and conditions, which documents attacker behaviour rather than the requirement being elicited. It is tempting because it is a recognised threat-modelling technique, and would be correct during design threat enumeration, not the Secure Software Requirements phase.
B
Misuse Case Modeling
Misuse case modelling documents adversarial goals against legitimate functionality, capturing the attacker's SQL injection intent as a structured abuse scenario. This satisfies the Secure Software Requirements phase constraint by recording the threat's behaviour during requirements, before design or code exists, so mitigations such as parameterised queries can be specified as explicit security requirements.
C
Data Flow Diagramming
Why it fails: Data Flow Diagramming maps how data moves between processes, stores and external entities; it shows trust boundaries but not the attacker's step-by-step injection behaviour. It is tempting because DFDs underpin threat modelling, and would be correct when documenting system architecture and data movement rather than a specific attack path.
D
Compliance Matrix Mapping
Why it fails: Compliance Matrix Mapping traces requirements to controls or regulations; it records coverage, not the mechanics of an injection threat. It is tempting because it is used in requirements phases, and would be correct when demonstrating that each security requirement maps to a standard or control framework.

Question 6hardmultiple choice

Which design activity helps identify security requirements during the earliest phases of the SDLC?

Trap 1: Penetration testing.

Penetration testing validates controls in a built system by actively exploiting weaknesses, so it cannot surface requirements before design exists. It is tempting as a security activity, yet it is correct only once code or infrastructure is deployed and needs assurance.

Trap 2: Incident response planning.

Incident response planning defines how the organisation detects, contains and recovers from breaches, so it presupposes threats already identified rather than eliciting them. It is tempting because it is a security design activity, but it belongs after requirements are set, when response procedures are documented.

Trap 3: Static code analysis.

Static code analysis inspects written source for defects, so it requires code that does not yet exist during earliest requirements phases. It is tempting because it finds security flaws, but it is correct during implementation or code review, not requirement elicitation.

A
Penetration testing.
Why it fails: Penetration testing validates controls in a built system by actively exploiting weaknesses, so it cannot surface requirements before design exists. It is tempting as a security activity, yet it is correct only once code or infrastructure is deployed and needs assurance.
B
Abuse case modeling.
Abuse case modelling examines how an attacker could misuse the application, deriving security requirements from anticipated threats during the earliest SDLC phases. Unlike functional use cases, it explicitly captures adversarial goals, feeding concrete protective requirements into design before code is written.
C
Incident response planning.
Why it fails: Incident response planning defines how the organisation detects, contains and recovers from breaches, so it presupposes threats already identified rather than eliciting them. It is tempting because it is a security design activity, but it belongs after requirements are set, when response procedures are documented.
D
Static code analysis.
Why it fails: Static code analysis inspects written source for defects, so it requires code that does not yet exist during earliest requirements phases. It is tempting because it finds security flaws, but it is correct during implementation or code review, not requirement elicitation.

Question 7easymultiple choice

A software development team is adopting a secure design principle that requires the security of a system to depend on the secrecy of the keys, not on the secrecy of the algorithm. Which principle are they implementing?

Trap 1: Fail-safe defaults

Fail-safe defaults dictate that access decisions should default to denial, and systems should fail in a secure state. This principle is about default permissions and failure modes, not about the secrecy of algorithms versus keys. The scenario is focused on the basis of security (key secrecy versus algorithm secrecy), so fail-safe defaults is not applicable.

Trap 2: Least privilege

Least privilege requires that subjects be given only the minimum access rights necessary to perform their tasks. It does not address whether security should depend on algorithm secrecy versus key secrecy. While important, it is unrelated to the specific principle described. Therefore, it is not the correct answer.

Trap 3: Security by obscurity

Security by obscurity relies on hiding the design or implementation details to achieve security. This is the opposite of the principle described. The scenario explicitly states that security should depend on the secrecy of keys, not the algorithm, which is a core tenet of open design. Security by obscurity is generally discouraged because it fails once the design is revealed.

A
Fail-safe defaults
Why it fails: Fail-safe defaults dictate that access decisions should default to denial, and systems should fail in a secure state. This principle is about default permissions and failure modes, not about the secrecy of algorithms versus keys. The scenario is focused on the basis of security (key secrecy versus algorithm secrecy), so fail-safe defaults is not applicable.
B
Least privilege
Why it fails: Least privilege requires that subjects be given only the minimum access rights necessary to perform their tasks. It does not address whether security should depend on algorithm secrecy versus key secrecy. While important, it is unrelated to the specific principle described. Therefore, it is not the correct answer.
C
Open design
Open design states that the security of a system should not depend on the secrecy of its design or implementation, but rather on the secrecy of keys or passwords. This aligns with Kerckhoffs's principle. By making the algorithm public and subject to scrutiny, vulnerabilities are more likely to be found and fixed. The scenario directly describes this principle, where security rests on key secrecy, not algorithm secrecy.
D
Security by obscurity
Why it fails: Security by obscurity relies on hiding the design or implementation details to achieve security. This is the opposite of the principle described. The scenario explicitly states that security should depend on the secrecy of keys, not the algorithm, which is a core tenet of open design. Security by obscurity is generally discouraged because it fails once the design is revealed.

Question 8easymultiple choice

A software development team is creating a new e-commerce application. During requirements elicitation, the security architect suggests using misuse cases to identify security requirements. Which of the following BEST describes the primary purpose of misuse cases in this context?

Trap 1: To create test cases for verifying that the application meets…

Test cases for performance benchmarks are unrelated to misuse cases. Misuse cases are used during requirements and design to identify security threats. Performance testing is a separate activity. Misuse cases do not typically address performance but rather security-related misuse and abuse.

Trap 2: To define the functional requirements for the checkout process.

Defining functional requirements for checkout is typically done through use cases or user stories. Misuse cases are not about normal functionality but about how the system could be misused. While checkout may have security aspects, misuse cases would focus on threats like payment fraud or data theft, not the standard flow.

Trap 3: To document normal user interactions with the system to ensure…

Documenting normal user interactions is the purpose of use cases, not misuse cases. Misuse cases focus on negative scenarios and potential attacks. While usability is important, it is not the primary goal of misuse cases, which are specifically designed to uncover security threats and derive security requirements.

A
To create test cases for verifying that the application meets performance benchmarks.
Why it fails: Test cases for performance benchmarks are unrelated to misuse cases. Misuse cases are used during requirements and design to identify security threats. Performance testing is a separate activity. Misuse cases do not typically address performance but rather security-related misuse and abuse.
B
To define the functional requirements for the checkout process.
Why it fails: Defining functional requirements for checkout is typically done through use cases or user stories. Misuse cases are not about normal functionality but about how the system could be misused. While checkout may have security aspects, misuse cases would focus on threats like payment fraud or data theft, not the standard flow.
C
To identify potential threats and attacks that the system must defend against.
Misuse cases are a technique to model negative scenarios where an actor intentionally harms the system or exploits vulnerabilities. They help elicit security requirements by identifying what the system should prevent or detect. This proactive approach ensures that security is considered early in the lifecycle, aligning with CSSLP principles.
D
To document normal user interactions with the system to ensure usability.
Why it fails: Documenting normal user interactions is the purpose of use cases, not misuse cases. Misuse cases focus on negative scenarios and potential attacks. While usability is important, it is not the primary goal of misuse cases, which are specifically designed to uncover security threats and derive security requirements.