Secure Software Requirements practice questions

The device must use a unique, per-device certificate for mutual authentication with the cloud.

Why it fails: Mutual authentication ensures that the device and cloud are legitimate, but it does not encrypt the data payload. While it establishes a secure channel, the data itself could still be transmitted in plaintext if encryption is not applied. This requirement addresses authentication, not data confidentiality, so it does not satisfy the need for data protection in transit and at rest.

The cloud backend must enforce role-based access control (RBAC) for all users accessing the sensor data.

Why it fails: RBAC controls who can access data but does not protect the data itself through encryption. It is an access control mechanism, not a data protection requirement for transit or rest. While important, it does not ensure confidentiality if the data is intercepted or the storage is compromised. Thus, it does not fulfill the specific need for encryption in transit and at rest.

The device must implement a secure boot process to verify firmware integrity before operation.

Why it fails: Secure boot is important for ensuring that only trusted firmware runs on the device, but it does not directly address data protection in transit or at rest. While it contributes to overall security, it is not a requirement for encrypting sensor data or stored data. This option is a distractor because it focuses on integrity of the device rather than confidentiality of data.

The application must log all authentication attempts and store logs for at least 30 days.

Why it fails: Logging authentication attempts is important for monitoring and incident response, but it is not a direct authentication mechanism. PCI DSS requires logging, but it is a detective control rather than a preventive one. This requirement alone does not ensure secure authentication and is not one of the most critical authentication requirements.

The application must implement a password complexity policy that requires at least 8 characters with a mix of letters and numbers.

Why it fails: While password complexity is a good practice, it alone is not sufficient for PCI DSS compliance in the context of sensitive account access. PCI DSS emphasizes MFA and secure storage over mere complexity. This requirement is weaker and does not address the primary risk of credential theft or replay attacks.

The application must allow users to authenticate using only a username and password to simplify the user experience.

Why it fails: Single-factor authentication with just username and password is insufficient for protecting sensitive financial data and violates PCI DSS requirements for MFA in many contexts. It increases the risk of credential compromise and does not meet the regulatory obligation to secure access to cardholder data. This requirement would weaken security.

Perform a network vulnerability scan

Why it fails: A vulnerability scan identifies known weaknesses on reachable hosts; it does not determine which systems handle cardholder data, so it cannot establish PCI-DSS scope. It is tempting because scanning is a mandated PCI-DSS control, but scoping precedes scanning and derives from data-flow analysis and system inventories.

Review the application source code

Why it fails: Source code review finds implementation flaws within one application; it cannot reveal which systems store, process or transmit cardholder data across the environment. It is tempting because code analysis supports PCI-DSS secure development requirements, but scope identification requires data-flow and cardholder data environment mapping.

Update the firewall rule set

Why it fails: Firewall rules control permitted traffic flows; they do not enumerate systems storing, processing or transmitting cardholder data, so they cannot define PCI-DSS scope. It is tempting because segmentation limits scope in practice, but scoping must first follow the cardholder data environment and connected-system inventory.

Immediately reject the request

Why it fails: Immediate rejection skips requirements analysis entirely, providing no documented rationale, risk evaluation, or alternative such as scoped test accounts. Rejection suits clearly prohibited requests, but here the first step is to analyse the requirement and its security implications before deciding.

Update the password policy

Why it fails: Updating the password policy presumes the exception is acceptable before analysing the request, and a blanket policy change would weaken controls for all accounts. Policy revision belongs after risk assessment and approval, not as the first step in requirements analysis.

Implement the bypass in dev only

Why it fails: Implementing the bypass in dev only still encodes a policy exception into the environment before any risk assessment or requirement definition occurs. Dev-only controls suit isolated sandbox testing, but requirements analysis must first evaluate the security impact and document the need.

GDPR

Why it fails: GDPR protects personal data of EU residents and does cover health data, but it is not the regulation specifically governing Protected Health Information in a US healthcare context. It is tempting because health data is a special category, yet HIPAA is the PHI-specific requirement.

FISMA

Why it fails: FISMA mandates security controls for US federal agencies and their contractors' information systems, not healthcare data handling. It is tempting because it references federal information security broadly, yet it says nothing about Protected Health Information; HIPAA governs PHI.

SOX

Why it fails: SOX governs financial reporting and internal controls for publicly traded companies, not clinical data. It is tempting in US-regulated industries where audit requirements overlap, but it imposes no rules on Protected Health Information; HIPAA is the regulation addressing PHI handling.

Threat Intelligence Feed

Why it fails: A threat intelligence feed supplies external indicators and adversary context; it is an input that may justify the SMS decision, not the artefact recording the requirement itself. It is tempting because SMS interception is a genuine threat, but the security team's determination must be documented as a requirement, not as intelligence data.

Change Request Log

Why it fails: A change request log records modifications to an approved baseline, so it captures the SMS decision only after the requirements baseline exists and someone raises a formal change. It is tempting because MFA decisions often surface mid-project, but here the security team is still gathering requirements, so the artefact must be the requirements documentation itself.

Project Charter

Why it fails: A project charter authorises the project and defines its high-level scope and objectives; it does not hold detailed security requirements such as banning SMS for administrative accounts. It is tempting as the earliest formal document, but the specific MFA constraint belongs in the requirements specification produced during requirements gathering.

Functional requirement

Why it fails: Encryption of service-to-service traffic is a quality attribute constraining how the system behaves, not a function it performs, so it belongs to non-functional requirements. Functional requirements are tempting because they describe system behaviour, but they specify what the system does, not the security constraint on how it does it.

Business rule

Why it fails: A business rule governs organisational policy or domain logic, not a technical security constraint on communication channels. Business rules are tempting because they also capture mandatory constraints, but they express operational policy decisions rather than the encryption quality attribute this requirement imposes on the architecture.

Use case description

Why it fails: A use case description documents actor interactions and expected system flows, not a cross-cutting security constraint. Use cases are tempting because they capture requirements in structured form, but they describe functional behaviour sequences, whereas encryption of service traffic is a non-functional quality attribute.

The Penetration Testing Report

Why it fails: A penetration testing report records discovered vulnerabilities and exploitation findings from a point-in-time assessment; it does not carry forward binding data lifecycle requirements into design. It would be the right artefact when tracking remediation of security flaws, not deletion obligations.

The Infrastructure-as-Code (IaC) templates

Why it fails: IaC templates declare provisioned infrastructure resources such as networks, compute and storage; they express deployment configuration, not data lifecycle requirements. They would be the right place for reproducible environment definitions, not for recording GDPR deletion obligations that shape architecture.

The Risk Register

Why it fails: The risk register captures identified risks, likelihood, impact and mitigation ownership; it does not specify functional deletion requirements that architects must implement. It would be correct for prioritising and tracking treatment of project risks, not for documenting GDPR erasure constraints.

Request a waiver for the legacy system

Why it fails: A waiver accepts the plaintext credential exposure rather than removing it, so the requirement still permits interception. It is tempting because legacy integrations often cannot be remediated immediately, and a waiver would be correct once compensating controls are documented and the residual risk is formally accepted by the business owner.

Suggest the use of a VPN for the entire network

Why it fails: A network-wide VPN encrypts transport between sites but not the application's own credential exchange, and the stem asks for a security requirement, not infrastructure. It is tempting because VPNs do protect data in transit, and would be correct if remote users needed encrypted access to internal resources generally.

Document the legacy protocol as a technical debt item

Why it fails: Documenting technical debt records the plaintext protocol without changing the requirement, leaving credentials exposed. It is tempting because legacy constraints are real and tracking debt is good practise, and would be correct if remediation were deferred and the risk formally accepted with compensating controls in place.

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.

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.

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.

To ensure user interface guidelines are followed

Why it fails: Misuse case modelling identifies how an attacker could abuse a system, capturing threat scenarios and negative requirements; it does not verify interface guideline adherence. It is tempting because it sits within requirements engineering, where usability checks also belong, but the axis is adversarial intent versus design conformance.

To identify all potential bugs in the code

Why it fails: Misuse cases model adversarial actors and abuse scenarios to derive security requirements, not enumerate code defects. It is tempting because both activities occur during secure development, and static analysis or code review would be correct when the goal is finding implementation bugs rather than anticipating attacker behaviour.

To document the project timeline

Why it fails: Misuse case modelling captures attacker goals and system responses, producing security requirements rather than scheduling artefacts. It is tempting because both are early-phase planning activities, and a work breakdown or Gantt chart would be correct when the objective is sequencing project tasks and milestones.

Implement multi-party authorization

Why it fails: Multi-party authorisation governs approval workflows for privileged actions; it neither validates a cryptographic module nor addresses FIPS 140-3 conformance testing. It is tempting because separation-of-duties controls appear in secure government deployments, and it would be correct where dual-control approval of key operations is the stated requirement.

Develop custom encryption algorithms

Why it fails: FIPS 140-3 validates standardised, approved algorithms; custom cryptography cannot be certified and would fail validation outright. It tempts because bespoke algorithms appear to offer unique protection, yet the standard requires NIST-approved modules such as AES and SHA-2.

Encrypt all databases at rest

Why it fails: Database encryption at rest is a data-protection control, not evidence of FIPS 140-3 validation of the cryptographic module itself. It is tempting because FIPS-approved algorithms often underpin such encryption, and it would be correct where the requirement is protecting stored data rather than certifying the module.

System Architecture Document

Why it fails: The System Architecture Document describes component structure and interfaces, not the mapping of regulatory clauses to features. It is tempting because architecture documents often reference security controls, and would be the right artefact when tracing how a design implements a specific control.

Incident Response Plan

Why it fails: An Incident Response Plan defines detection, containment and recovery procedures, not feature-to-regulation traceability. It is tempting because compliance frameworks mandate incident handling, so the plan evidences one control, but it cannot map each regulatory requirement to the software feature satisfying it.

Software Development Plan

Why it fails: The Software Development Plan covers process, schedule and methodology, not the linkage of regulatory clauses to features. It is tempting because it governs how features are built and references security activities, but the requirement-to-feature mapping belongs in the Software Requirements Specification.

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.

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.

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.

Slow deployment speeds

Why it fails: Shadow IT's core problem is unauthorised systems escaping governance, so their security requirements are never gathered or assessed. Slow deployment tempts because it is a genuine frustration that drives staff to bypass IT, but speed is the cause, not the requirements-gathering challenge itself.

High infrastructure costs

Why it fails: Shadow IT typically lowers visible infrastructure cost by using external SaaS, so cost is not the primary requirements challenge; the real issue is ungoverned systems whose security needs are undocumented. Cost tempts because centralised infrastructure is expensive, and it would be the answer if the stem concerned budget consolidation.

Excessive user training

Why it fails: Training burden is a downstream consequence, not the primary challenge; shadow IT's defining problem is that unauthorised systems sit outside requirements gathering entirely. It tempts because unapproved tools do demand user education, and that would be correct if the question asked about onboarding effort after discovery.

Maintenance phase

Why it fails: Maintenance addresses defects after production release, when fixes incur the highest cost plus operational risk. It is tempting because maintenance includes security patching, but requirement flaws should be identified during requirements definition, not after deployment.

Deployment phase

Why it fails: Deployment is where code is already released, so flaws in security requirements force costly rework and patching. It is tempting because deployment testing catches configuration errors, but requirement defects must be found earlier, during requirements definition, where correction costs least.

Testing phase

Why it fails: Testing detects requirement defects only after design and code are built, so remediation requires reworking artefacts. It appeals because testing validates implemented behaviour, yet requirements errors are cheapest to fix during the requirements phase, before any downstream work exists.

Use the largest possible key size

Why it fails: Key size strengthens cryptographic resistance but addresses only one control; Privacy by Design requires proactive embedding of privacy throughout the lifecycle, including minimisation and consent. It is tempting because larger keys harden encryption, and would be the right focus for a cryptography strength requirement.

Implement full data retention

Why it fails: Full data retention keeps PII indefinitely, conflicting with storage limitation and data minimisation principles central to Privacy by Design. It is tempting because retaining data supports auditing and analytics, and would be justified only where a specific legal or regulatory obligation mandates retention.

Outsource all PII processing

Why it fails: Outsourcing PII processing transfers operations but not accountability; the organisation remains responsible for safeguards, so it does not itself demonstrate Privacy by Design. It is tempting because it shifts processing burden, and would be acceptable where a processor meets contractual and regulatory requirements.

Ignore the usability concern

Why it fails: Discarding the usability concern leaves a requirement conflict unresolved and produces controls users will bypass, undermining the security objective itself. It is tempting when usability is seen as a non-security matter outside the team's remit, but secure requirements must address both, and ignoring one side fails the analysis the stem demands.

Always prioritize security over usability

Why it fails: Blanket prioritisation of security over usability ignores the requirement to balance both, producing controls that users circumvent or that block legitimate business function. It is tempting because security is the team's mandate and some regulated contexts genuinely demand strict controls, but conflicts must be resolved through documented risk analysis, not a fixed rule.

Ask the developers to make the final decision

Why it fails: Developers lack the risk-assessment context and accountability for security trade-offs, so delegating the decision leaves requirements unresolved and unverifiable. It is tempting because developers own implementation and usability, and their input is valuable when refining requirements — but the security team must document and resolve the conflict, not abdicate it.

The annual maintenance budget

Why it fails: Abuse cases model attacker goals and misuse scenarios against a system, so they derive from threat intelligence and attacker behaviour, not finance. A maintenance budget is tempting because it constrains security spending, but it belongs to cost planning, not abuse-case development.

Developer performance metrics

Why it fails: Abuse cases derive from attacker goals, threat intelligence and misuse scenarios, not from how well developers perform. Developer metrics are tempting because they feed process improvement and capacity planning, and would be relevant to retrospectives or estimation, not to modelling adversarial behaviour.

The internal office floor plan

Why it fails: Abuse cases require attacker-centric inputs such as threat models and misuse scenarios; a floor plan describes physical layout and reveals nothing about adversarial goals or system misuse. It is tempting because physical security reviews use building layouts, so it would be correct for assessing perimeter or facility access controls.

Prioritize HIPAA over local laws

Why it fails: Prioritising HIPAA ignores that local privacy laws often impose stricter or additional obligations, such as consent, breach notification timelines, or data residency, which HIPAA does not pre-empt. It tempts because HIPAA sets a recognised federal floor for protected health information. Where no conflicting local statute exists, aligning solely to HIPAA would suffice.

Follow only the most recent regulation

Why it fails: Following only the most recent regulation ignores that HIPAA and local privacy laws impose cumulative, independent obligations — newer does not supersede older where both apply, so a control satisfying one may breach the other. It tempts when regulations genuinely conflict and a single governing framework exists, such as choosing the latest version of one standard.

Create separate modules for each regulation

Why it fails: Separate modules duplicate controls and cannot resolve conflicts where HIPAA and local privacy law impose divergent retention or breach-notification duties, leaving the system with contradictory behaviour. Modularisation suits isolating distinct functional domains, such as payment processing from user profiles, where requirements do not overlap or clash.