SECURE-SOFTWARE-DESIGN Practice Questions

The practice of adding restrictions to field lengths and the types of data accepted is known as input validation. This is a critical secure coding practice that ensures data submitted by a user conforms to predefined rules before it is processed by the application. By enforcing constraints on data length, format, and content at the user interface (UI), developers can prevent a wide range of vulnerabilities, including buffer overflows, cross-site scripting (XSS), and SQL injection, which often rely on submitting malformed or malicious input.

B. Access control determines a user's permissions to access resources or perform actions, not the validity of the data they enter.

C. Communication security focuses on protecting data during its transmission over a network (e.g., using TLS/SSL), not on validating it at the point of entry.

D. Data protection is a broad term encompassing all measures to secure data; input validation is a specific technique within this larger category, making it the more precise answer.

1. OWASP Foundation. "Input Validation Cheat Sheet." OWASP Cheat Sheet Series. The document states, "Input validation is performed to ensure only properly formed data is entering the workflow... it is critical to check that the supplied data is of the correct type, length, format, and within range before it is processed." This directly aligns with the scenario of restricting field lengths and accepted data.

2. National Institute of Standards and Technology (NIST). (2020). Special Publication 800-53, Revision 5: Security and Privacy Controls for Information Systems and Organizations. Section: System and Information Integrity (SI), Control SI-10: Information Input Validation. This control mandates organizations to "validate information input to the system to ensure that it is determined to be valid" and includes checks for data type and length as part of the validation process.

3. Viega, J., & McGraw, G. (2002). Building Secure Software: How to Avoid Security Problems the Right Way. Addison-Wesley. In Chapter 5, "Handling Input," the authors emphasize that "all input is evil until proven otherwise" and detail the necessity of validating input for length, character set, and format to prevent security flaws. (p. 81-85).

The scenario describes a successful brute-force attack, where an automated tool made hundreds of login attempts against a single username. The fundamental security failure is that the system's authentication mechanism did not prevent or mitigate this high volume of repeated attempts. Implementing brute-force resistance, such as account lockout after a certain number of failed attempts, rate limiting, or CAPTCHA challenges, would directly thwart this attack vector by making it impractical for an attacker to try hundreds of passwords in a short period.

A. Ensure passwords are encrypted when stored in persistent data stores: This control protects passwords at rest (e.g., in a database) but does not prevent an attacker from making live login attempts against the authentication endpoint.

C. Ensure strong password policies are enforced: While a strong password policy makes guessing harder, it does not stop the attack method itself. The core vulnerability is allowing unlimited or a high number of guesses.

D. Ensure credentials and authentication tokens are encrypted during transit: This protects against man-in-the-middle (MITM) attacks by securing data on the network. It does not defend the login form from being targeted by brute-force attempts.

---

1. OWASP Application Security Verification Standard (ASVS) v4.0.3. This standard explicitly calls for protection against brute-force attacks as a key authentication control.

Reference: Section V2: Authentication Verification Requirements, Control 2.2.1: "Verify that the application has a mechanism to protect against credential stuffing, password spraying, and brute-force attacks on all authentication endpoints, such as by using account lockouts, rate limiting, or CAPTCHA." This directly supports implementing controls to resist brute-force attacks.

2. NIST Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management. This publication provides federal guidance on authentication systems and emphasizes the need for brute-force mitigation.

Reference: Section 5.2.2, Brute Force Mitigation: "The verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on an account... The mechanism can be implemented on a per-account basis, on a per-IP-address basis, or on any other basis that the verifier deems appropriate."

3. Saltzer, J. H., & Schroeder, M. D. (1975). The Protection of Information in Computer Systems. Communications of the ACM, 18(7), 387-402. This foundational paper on computer security principles, often cited in university curricula, discusses the importance of limiting exposure. Allowing unlimited login attempts violates the principle of minimizing attack surfaces.

Reference: Section I.A.3, Psychological Acceptability: While not a direct technical control, the principles imply that systems should not have easily exploitable mechanisms. A system allowing hundreds of login attempts is not psychologically acceptable from a security design standpoint and fails to limit the attack mechanism. (This is a foundational reference supporting the why behind the technical control).

DOI: https://doi.org/10.1145/361011.361062

Secure session management is a critical best practice of secure coding. It involves the correct implementation of mechanisms to handle the life cycle of a user's session, from login to logout. Developers must write code that generates strong, unpredictable session identifiers, protects them in transit and at rest, and properly invalidates them upon termination. Failure to implement secure session management can lead to severe vulnerabilities such as session hijacking, session fixation, and cross-site request forgery (CSRF), allowing attackers to impersonate legitimate users and gain unauthorized access to the system.

A. Planning is a high-level phase in the software development lifecycle (SDLC) that precedes coding; it is not a coding practice itself.

C. User acceptance testing is a validation phase that occurs after coding is complete to ensure the software meets business requirements.

D. Microservices is an architectural style for structuring an application. While it has security implications, it is not a specific coding practice.

1. OWASP Application Security Verification Standard (ASVS) v4.0.3, Section V3: Session Management Verification Requirements. The standard dedicates an entire section to the requirements for securely implementing session management at the application level, establishing it as a core secure development practice.

2. OWASP Top 10: 2021, A07:2021-Identification and Authentication Failures. This category explicitly states that weaknesses related to session management, such as session identifiers not being invalidated after logout, are a primary cause of authentication failures. This highlights its importance in secure coding.

3. NIST Special Publication 800-218, Secure Software Development Framework (SSDF) Version 1.1, Section 4, Practice PW.8: "Conform to secure coding practices." The details of this practice include following standards for specific security concerns, of which session management is a well-established example.

4. Saltzer, J. H., & Schroeder, M. D. (1975). The Protection of Information in Computer Systems. Communications of the ACM, 18(7), 387-408. While a foundational text, its principles, such as complete mediation and least privilege, directly inform modern secure coding practices like validating session state on every request (a key part of secure session management). (DOI: https://doi.org/10.1145/360813.360818)

The final vulnerability score, after adjusting for temporal and environmental metrics, is 8.0. According to the Common Vulnerability Scoring System (CVSS) v3.1 specification, scores are mapped to qualitative severity ratings. A score in the range of 7.0 to 8.9 is classified as "High" severity. While the initial base score of 9.9 was "Critical," the environmental and temporal metrics, which reflect the specific context of the organization's deployment, adjusted the final score into the "High" category. The final, context-adjusted score is the most accurate representation of risk for the organization.

A. Medium severity: This rating corresponds to scores between 4.0 and 6.9, which is lower than the final score of 8.0.

B. Critical severity: This rating corresponds to scores from 9.0 to 10.0. The initial base score was critical, but the final adjusted score is not.

C. Low severity: This rating corresponds to scores between 0.1 and 3.9, which is significantly lower than the final score of 8.0.

---

1. FIRST.org, Inc. (2019, June). Common Vulnerability Scoring System v3.1: Specification Document. Section 5, "Qualitative Severity Rating Scale," Table 14. This official specification document defines the severity rating scale. It explicitly states that a score of 7.0 - 8.9 is rated as "High."

2. National Institute of Standards and Technology (NIST). (n.d.). NVD Common Vulnerability Scoring System Calculator. National Vulnerability Database. Retrieved from https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator. The official NVD calculator, an implementation of the CVSS standard, displays the qualitative ratings corresponding to the score ranges, confirming that 8.0 is "High."

3. Carnegie Mellon University, Software Engineering Institute (SEI). (n.d.). A Complete Guide to the Common Vulnerability Scoring System (CVSS). Retrieved from https://www.sei.cmu.edu/our-work/vulnerability-analysis/vuln-analysis-resources/cvss/. This resource from a reputable research institution explains the CVSS framework and confirms the standard severity rating scale (Low, Medium, High, Critical) and their corresponding numerical score ranges.

Unmitigated threats are specific, identified threats for which no security controls, countermeasures, or defenses have been implemented. In the context of threat modeling and risk assessment, after a threat is identified, it is analyzed to determine the risk it poses. If a decision is made not to apply a defense (e.g., due to cost, complexity, or risk acceptance), the threat remains unmitigated. This leaves the corresponding vulnerability in the application exposed and susceptible to exploitation by an attacker.

A. Fully mitigated threat: This describes a threat that has been effectively addressed by implementing one or more security controls, neutralizing the risk.

B. Threat profile: This is a broader concept that describes the types of attackers, their motivations, and the attack vectors relevant to an application, not the mitigation status of a single threat.

D. Partially mitigated threat: This refers to a threat where some defenses have been applied, but they are incomplete or do not fully address the associated risk.

---

1. National Institute of Standards and Technology (NIST). (2012). Special Publication (SP) 800-30 Revision 1, Guide for Conducting Risk Assessments.

Reference: Section 2.4, "Risk Response," page 21.

Explanation: This guide outlines risk response strategies. The "Risk Acceptance" strategy involves a decision to take no action to alter the risk. A threat associated with an accepted risk for which no controls are implemented is, by definition, an unmitigated threat.

2. Shostack, A. (2014). Threat Modeling: Designing for security. Wiley.

Reference: Chapter 16, "Managing and Documenting Threats," pages 315-317.

Explanation: This foundational text on threat modeling discusses the lifecycle of a threat, including tracking its mitigation status. Threats are often filed as bugs or work items and are considered open or "unmitigated" until a developer implements a fix or a conscious decision is made to accept the risk without a fix.

3. OWASP Foundation. (2021). Application Security Verification Standard (ASVS) 4.0.3.

Reference: Section V1.1, "Threat Modeling," Requirement 1.1.1.

Explanation: The standard requires that threat modeling results in a documented list of threats. For each threat, the organization must document either the "recommended controls" (mitigation) or the "acceptance of the risk." A threat where the risk is accepted without controls is an unmitigated threat.

The scenario describes the initial stage of a project where a high-level business concept ("untapped revenue stream") is presented to determine its viability ("determine whether to move forward"). This activity is characteristic of the Planning phase of the Software Development Lifecycle (SDLC). This phase focuses on project initiation, feasibility analysis, defining the initial scope, and securing stakeholder buy-in before any detailed requirements are gathered or design work begins. The meeting between leadership and IT to share a "vision" is a classic example of this preliminary planning and feasibility assessment.

A. Implementation: This phase involves writing the actual code for the software, which occurs much later in the lifecycle after design is complete.

B. Design: This phase focuses on creating the system architecture and detailed component specifications based on established requirements, which have not yet been defined.

D. Requirements: This phase involves gathering and documenting detailed functional and non-functional specifications from stakeholders, which happens after the project has been approved in the planning phase.

1. Sommerville, I. (2016). Software Engineering (10th ed.). Pearson. In Chapter 2, Section 2.1.1, "Software specification," the author describes the first stage as establishing the "goals of the system" and conducting a "feasibility study," which aligns with the Planning phase. The text states, "The first stage in the software process is to understand and define what services are required from the system and to identify the constraints on its operation and development." This is precisely what the meeting between leadership and IT aims to initiate.

2. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill Education. Chapter 4, "An Introduction to Process," describes the initial "Communication" activity (part of planning) as involving stakeholder collaboration to "define the primary objectives for the project." The scenario's meeting to share a vision and decide whether to proceed is a core part of this initial communication and planning framework.

3. MIT OpenCourseWare. (2005). 6.170 Laboratory in Software Engineering, Fall 2005. Lecture Notes, Lecture 1: The Software Lifecycle. The lecture outlines the "waterfall" model, starting with a phase that involves understanding the problem and determining feasibility, which is synonymous with the Planning phase described in the question. This precedes the detailed "Requirements" phase.

The "Analyze the Target" phase of threat modeling, often called "Decompose the Application," is where the system's architecture is broken down to be understood. A critical activity in this step is to identify the system's assets—the valuable data, processes, or resources that require protection. This involves creating diagrams (like Data Flow Diagrams) to visualize components, data flows, and trust boundaries. By identifying assets early in this analysis phase, security efforts can be properly focused on protecting what is most valuable to the organization and most attractive to an attacker.

A. Set the Scope: This step defines the boundaries of the threat model (what is in and out of scope) rather than identifying specific assets within the system.

C. Rate Threats: This step occurs later in the process to prioritize identified threats based on risk; it does not involve the initial identification of assets.

D. Identify and Document Threats: This step uses the system model (including its assets) to brainstorm potential threats (e.g., using STRIDE), but it follows the asset identification step.

1. Microsoft Security Development Lifecycle (SDL): In the official Microsoft threat modeling process, the second step is "Decompose the application." This step explicitly includes "identifying assets, trust boundaries, and entry/exit points" as part of understanding the application. This is synonymous with "Analyze the Target."

Source: Microsoft Docs, "Threat modeling process," Step 2: Decompose the application. (Retrieved from Microsoft's official documentation on the Security Development Lifecycle).

2. OWASP Threat Modeling Cheat Sheet: The OWASP methodology outlines a similar process. The first phase, "Decompose the Application," states that the goal is to understand the application, which involves identifying "entry points, assets, and trust levels."

Source: OWASP Foundation, "Threat Modeling Cheat Sheet," Section: "Phase 1 - Decompose the Application."

3. Academic Publication: The seminal book on the topic, Threat Modeling: Designing for Security, frames the process around four key questions. The first question, "What are we working on?", involves modeling the system. A core part of this modeling is understanding and listing the system's assets.

Source: Shostack, A. (2014). Threat Modeling: Designing for Security. Wiley. Chapter 3, "What Are You Building?", Section: "Assets."

The technique described is Source-Code Fault Injection (SCFI). This white-box testing method involves deliberately inserting errors (faults) directly into the software's source code. By cloning the repository and modifying code snippets, the security team is simulating software bugs or unexpected states to observe the system's response. The primary goal is to assess the software's robustness, error handling capabilities, and overall resilience. This method provides a high degree of control over the location and type of faults introduced, allowing for targeted vulnerability testing before the code is compiled and deployed.

B. Dynamic Code Analysis: This method tests a running application by providing external inputs to identify vulnerabilities, without modifying the source code itself.

C. Fuzz Testing: This is a specific type of dynamic analysis that involves sending large amounts of malformed or random data as input, not altering the program's code.

D. Binary Fault Injection: This technique injects faults into the compiled machine code (binary/executable), not the human-readable source code as described in the scenario.

---

1. Natella, R., Cotroneo, D., & Arlat, J. (2023). Software Fault Injection. In ACM Computing Surveys, 55(8), 1-37. In Section 3.1, "Compile-time injection," the authors describe this technique: "Faults are injected into the source code of the software, before the compilation... This approach is also known as source code instrumentation or source code modification." (p. 8). https://doi.org/10.1145/3564923

2. Voas, J. M., & McGraw, G. (1998). Software Fault Injection: Inoculating Programs Against Errors. John Wiley & Sons. Chapter 3, "Code-Based Fault Injection," details the process of altering source code to create faults. It distinguishes this from operational or data-based fault injection methods.

3. Meixner, A., & Goseva-Popstojanova, K. (2009). A Framework for Comparison of Software Fault Injection Tools. In 2009 20th International Symposium on Software Reliability Engineering (pp. 247-256). IEEE. The paper categorizes fault injection techniques, defining source code injection (compile-time injection) as the modification of high-level language source code to inject faults, contrasting it with binary-level injection and runtime injection. (Section II.A, p. 248). https://doi.org/10.1109/ISSRE.2009.33

4. Koopman, P. (2021). ECE 18-649, Lecture 11: Dependability & Fault Injection. Carnegie Mellon University. The course lecture notes differentiate between various fault injection methods, specifying that source-level injection involves "modifying source code to inject faults (e.g., mutation testing)." This aligns directly with the scenario. (Slide 21).

A Product Security Incident Response Team (PSIRT) follows a structured process for handling vulnerability reports. A formal public disclosure, which includes assigning a CVE ID and CVSS scores, is a critical step in the Coordinated Vulnerability Disclosure (CVD) lifecycle. This action is only taken after the PSIRT has completed its internal investigation and triage process, which involves validating the report, reproducing the issue, and confirming its security impact. Therefore, the determination that the vulnerability is credible and affects the product is the fundamental prerequisite and primary reason for proceeding with a formal public disclosure to inform customers and the security community.

A. Increased public awareness leading to higher risk is a potential negative outcome that disclosure aims to mitigate with patches, not the reason for the disclosure itself.

B. A PSIRT would not issue a formal CVE and CVSS score for a vulnerability it has determined is not credible; such a report would be closed or rejected.

D. Notification from an external party only initiates the investigation process; it does not automatically trigger a public disclosure without prior validation and confirmation of credibility.

1. FIRST.org, "PSIRT Services Framework," Version 1.1, Section 3.3, Vulnerability Handling (p. 13). The framework outlines the typical PSIRT workflow as Triage -> Investigation -> Remediation -> Disclosure. This sequential process shows that disclosure occurs only after the investigation phase, where the credibility and impact of a potential vulnerability are determined.

2. Carnegie Mellon University, Software Engineering Institute (SEI), "The CERT Guide to Coordinated Vulnerability Disclosure," (2017), Section 4.2, "Analysis" (p. 21). This guide details the vulnerability analysis phase, stating, "The goal of the analysis phase is to understand a vulnerability report well enough to determine whether it describes a true vulnerability in your product or service." This confirmation is a necessary step before any disclosure activities are planned.

3. ISO/IEC 29147:2018, "Information technology — Security techniques — Vulnerability disclosure," Section 6.3, "Triage." This international standard specifies that after receiving a report, the vendor must perform a triage to "determine the report's accuracy and credibility." A decision to proceed is based on this initial validation, which precedes public disclosure.

A Risk Mitigation Plan is the specific architecture deliverable that documents an organization's strategy for managing identified security risks. This plan is created after a risk assessment and is directly informed by the organization's risk tolerance—the level of risk it is willing to accept. The plan outlines specific controls and actions to reduce risks to an acceptable level. Crucially, it also includes contingency and incident response strategies, which define precisely how the organization will react if a security issue or incident occurs, thereby addressing both parts of the question.

A. Threat Modeling Artifacts: These documents identify and analyze potential threats and vulnerabilities but do not define the organization's risk tolerance or its official response plans.

C. Business Requirements: These define the high-level goals and needs for the system, which inform security policies and risk tolerance, but they are not the plan for mitigation or reaction.

D. Policy Compliance Analysis: This is a verification artifact that assesses whether the system design adheres to established policies; it does not create the risk response strategy itself.

---

1. NIST Special Publication 800-37, Revision 2, "Risk Management Framework for Information Systems and Organizations."

Section 2.5, "Step 4: Implement," discusses how organizations implement the risk responses identified in the risk response plan. It states, "The risk response strategy is the course of action to be taken regarding the risk... Risk response options include acceptance, avoidance, mitigation, sharing, or transferring the risk." The mitigation plan documents these choices.

Appendix F, "Risk Mitigation Plan," describes the plan's purpose as documenting the "planned implementation of controls" and the "course of action to address the vulnerabilities in the system." This includes reactive measures.

2. Carnegie Mellon University, Software Engineering Institute (SEI), "The CERT® Resilience Management Model (CERT-RMM) v1.2."

Process Area: Risk Management (RISK), Specific Goal 3 (SG 3), "Handle risks." This section details the need to "Develop a risk mitigation plan for risks that are not accepted." This explicitly links the concept of risk acceptance (tolerance) to the creation of a mitigation plan that includes response actions.

3. Ross, R., McEvilley, M., & Oren, J. C. (2016). "Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems" (NIST Special Publication 800-160, Vol. 1).

Section 3.3.4.4, "Risk Response," states that a key part of the risk management process is to "develop a risk response strategy" and that "The risk response is implemented through a risk mitigation plan." This confirms the plan is the deliverable containing the response strategy based on tolerance.