WGU Secure-Software-Design WGU Secure Software Design (D487, KEO1) Exam Exam Practice Test

The Common Vulnerability Scoring System (CVSS) uses the following ranges to determine the severity rating of a vulnerability:

0.1 - 3.9: Low severity

4.0 - 6.9: Medium severity

7.0 - 8.9: High severity

9.0 - 10.0: Critical severity

Since the adjusted score for the vulnerability is 5.9, it falls within the High severity range.

ASF Authentication Threats: The Web Application Security Frame (ASF) authentication category encompasses threats related to how users and systems prove their identity to the application. This includes issues like weak passwords, compromised credentials, and inadequate access controls.

Role-Based Access Control (RBAC): RBAC is a well-established security principle that aligns closely with addressing authentication threats. It involves assigning users to roles and granting those roles specific permissions based on the principle of least privilege. This limits the attack surface and reduces the impact of a compromised user account.

Let's analyze the other options:

B. Credentials and tokens are encrypted: While vital for security, encryption primarily protects data at rest or in transit. It doesn't directly address authentication risks like brute-force attacks or weak password management.

C. Cookies have expiration timestamps: Expiring cookies are a good practice, but their primary benefit is session management rather than directly mitigating authentication-specific threats.

D. Sensitive information is scrubbed from error messages: While essential for preventing information leakage, this practice doesn't address the core threats within the ASF authentication category.

The DKEAD category that has a risk rating based on the threat exploit’s potential level of harm is Damage potential. This category assesses the total damage or impact that a threat could cause if it is exploited by an attacker. The risk rating in this category is determined by evaluating the severity of the potential damage, which could range from information disclosure to complete system destruction or loss of system availability.

The Intelligence domain in the Building Security in Maturity Model (BSIMM) focuses on gathering and using information about software security. This includes understanding the types of attacks that are possible against the software being developed, which is why reviewing attack models falls under this domain. The BSIMM domain of Intelligence involves creating models of potential attacks on software (attack models), analyzing actual attacks that have occurred (attack intelligence), and sharing this information to improve security measures. By reviewing attack models, the software security group is essentially assessing the organization’s ability to anticipate and understand potential security threats, which is a key aspect of the Intelligence domain.

 Session management is a core component of secure coding, which involves maintaining the state of a user’s interaction with a system. Proper session management can help protect against various security vulnerabilities, such as session hijacking and session fixation attacks. It is essential for ensuring that user data is handled securely throughout an application’s workflow.

The deliverable that would aid a software security team in preparing a detailed schedule mapping security development lifecycle phases to the type of analysis they will execute is Security test plans. These plans are crucial as they outline the testing strategies and specific security tests that will be conducted during the development lifecycle to ensure the software meets the required security standards.

Security test plans are developed after the requirements and design phases and are used throughout the implementation, verification, and release phases. They include detailed instructions for security testing, criteria for success, and the types of security testing to be performed, such as static and dynamic analysis, penetration testing, and code review.

These plans are living documents that should be updated as new threats are identified and as the project evolves. They ensure that all team members understand the security goals, the risks, and the measures that need to be taken to mitigate those risks.

By having a well-defined security test plan, the team can ensure that security is not an afterthought but is integrated into every phase of the software development lifecycle, thus producing more secure software.

Manual peer review refers to the systematic examination of software source code by developers other than the original author. This practice is recognized as a valuable tool for reducing software defects and improving the quality of software projects. It involves developers inspecting the code to find and fix mistakes overlooked in the initial development phase, which enhances both the overall quality of software and the developers’ skills. Peer code review is less formal and more “lightweight” than the code inspections performed in the past, and it provides benefits such as knowledge transfer, increased team awareness, and creation of alternative solutions to problems.

The privacy impact statement requirement that defines how personal information will be protected when authorized or independent external entities are involved is best categorized under Third party requirements. This aspect of privacy impact assessments ensures that personal data is safeguarded even when it is necessary to involve third parties, which could be service providers, partners, or other entities that might handle personal information on behalf of the primary organization. These requirements typically include stipulations for data handling agreements, security measures, and compliance checks to ensure that third parties maintain the confidentiality and integrity of the personal information they process.

Security change management within the change management process involves ensuring that any changes, including updates or modifications to software, do not introduce new vulnerabilities and are in line with security policies. The question about securing remote administration directly reflects this component because it addresses the security considerations that must be managed when changes are made to how software is accessed and controlled remotely. This includes implementing secure protocols, authentication methods, and monitoring to prevent unauthorized access or breaches, which are crucial when managing changes in a secure manner.

The activity described pertains to the review of noncommercial software libraries to ensure compliance with the legal specifications set by the authors. This is part of the open-source licensing review, which is a critical activity in the Ship phase of the Security Development Lifecycle (SDL). This review ensures that all open-source components are used in accordance with their licenses, which is essential for legal and security compliance.

Comprehensive and Detailed Explanation From Exact Extract:

A Threat profile is a security assessment deliverable that outlines and identifies possible security vulnerabilities and threats relevant to a product. It includes categorization of threats, their potential impact, and vectors through which the product can be attacked. This deliverable is crucial for guiding mitigation and security testing efforts. Metrics templates (B) track progress or measurements, SDL project outline (C) documents phases and tasks in the secure development lifecycle, and the list of third-party software (D) catalogs external dependencies but does not specifically identify vulnerabilities. As per Microsoft SDL and OWASP Threat Modeling, the threat profile is a foundational deliverable in risk assessment and vulnerability identification.

 The three primary goals of the secure software development process, often referred to as the CIA triad, are confidentiality, integrity, and availability. These principles form the cornerstone of security considerations in the software development life cycle (SDLC).

Confidentiality ensures that sensitive information is accessed only by authorized individuals and systems. This involves implementing access controls and encryption to protect data from unauthorized access.

Integrity refers to maintaining the accuracy and consistency of data across its lifecycle. This means that the data is not altered or tampered with by unauthorized entities. Techniques like checksums and digital signatures help ensure data integrity.

Availability ensures that information and resources are accessible to authorized users when needed. This involves creating resilient systems that can withstand attacks and recover quickly from any disruptions.

By integrating these security goals into each phase of the SDLC, from planning and design to development, testing, and maintenance, organizations can create more secure software systems that are resilient to cyber threats.

The phase being described is the Design phase of the SDLC. During this phase, developers and IT staff determine the architectural and operational details of the product, which includes decisions on how to deliver various components such as secure REST services, mobile apps, and web applications. The Design phase is crucial for setting the foundation for the development work that will follow, ensuring that the product will be secure, scalable, and maintainable.

The software control test that examines an application from a user perspective by providing a wide variety of input scenarios and inspecting the output is known as black box testing. This testing method focuses on the functionality of the application rather than its internal structures or workings. Testers provide inputs and examine outputs without knowing how and where the inputs are worked upon. It’s designed to test the system’s external behavior.

Black box testing is used to verify that the system meets the requirements and behaves as expected in various scenarios, including edge cases and incorrect input data. It helps in identifying discrepancies between the system’s actual functionality and its specified requirements.

This type of testing is applicable across various levels of software testing, including unit, integration, system, and acceptance testing. It is particularly useful for validating user stories and use cases during the software development process.

Since black box testing treats the software as a “black box”, it does not require the tester to have knowledge of the programming languages or the system’s implementation. This allows testers to objectively test the software’s behavior and performance.

The secure coding practice being described is Access Control. This practice ensures that access to data and features within a system is restricted and controlled. The description given indicates that the product has mechanisms to prevent the display of personally identifiable information (PII), restrict the printing of private documents, and require elevated privileges to access archived documents. These are all measures to control who has access to what data and under what circumstances, which is the essence of access control.

Static analysis is a method used to detect vulnerabilities in software without executing the code. It involves examining the codebase for patterns that are indicative of security issues, such as SQL injection vulnerabilities. This technique can identify potential threats and weaknesses by analyzing the code’s structure, syntax, and data flow.

The step in threat modeling that involves collecting exploitable weaknesses within the product is Identify and document threats. This step is crucial as it directly addresses the identification of potential security issues that could be exploited. It involves a detailed examination of the system to uncover vulnerabilities that could be targeted by threats.

White box testing, also known as clear box testing, glass box testing, transparent box testing, and structural testing, is a method of software testing where the internal structure, design, and coding of the software are tested to verify the flow of input-output and to improve the design, usability, and security. It involves looking at the structures that are internal to the system, with the tester having knowledge of the internal workings of the product. This type of testing is concerned with examining the internal logical structures of the program and is typically performed by stepping through the code line by line to analyze the program for potential errors, which aligns with the description of the control test in question.

Fuzzing is an automated or semi-automated software testing technique that involves providing invalid, unexpected, or random data to the inputs of a computer program1. This process is designed to uncover coding errors, security vulnerabilities, and other potential issues within the software by observing how it behaves under unexpected or malformed inputs. Fuzzing is particularly effective because it can expose corner cases that have not been properly dealt with and can be used to test programs that take structured inputs, such as file formats or protocols2.

Security testing reports are the most likely deliverables to contain detailed records of evaluations, their frequency, and re-evaluations. Here's why:

Purpose of Security Testing Reports: These reports document the results of security testing, including:

Types of tests: Vulnerability scans, penetration tests, code reviews, etc.

Frequency: How often tests were conducted (e.g., per build, per release cycle).

Re-evaluations: If vulnerabilities were discovered, these reports will track whether and how often those were retested after remediation.

Focus on Testing: The question specifically emphasizes evaluations, which aligns with the core content of security testing reports.

The security testing technique that involves using a testing tool to scan a running application for known exploit signatures is known as Automated Vulnerability Scanning. This method is part of dynamic analysis, which assesses the software in its running state to identify vulnerabilities that could be exploited by attackers. Automated vulnerability scanning tools are designed to detect and report known vulnerabilities by comparing the behavior and outputs of the application against a database of known exploit signatures1.

Comprehensive and Detailed Explanation From Exact Extract:

The Iterative software development model fits this description. It involves specifying and implementing a portion of the software, reviewing it, gathering feedback, and refining or adding requirements in successive cycles. This approach supports evolving requirements and continuous improvement. Iterative models contrast with Waterfall (C), which is linear and sequential, with no repetition of phases. “Code and fix” (D) is an informal, ad hoc process lacking formal review cycles. Implementation (B) is a phase, not a model. The iterative approach is advocated in ISO/IEC 12207 and NIST guidelines for secure development, as it allows early detection and remediation of security issues by incremental design and testing.

The secure coding best practice that recommends using a single application-level authorization component to lock down the application if it cannot access its configuration information is known as Access Control. This practice is part of a broader set of security measures aimed at ensuring that only authorized users have access to certain functionalities or data within an application. By centralizing the authorization logic, it becomes easier to manage and enforce security policies consistently across the application. If the authorization component cannot retrieve its configuration, it defaults to a secure state, thus preventing unauthorized access1.

Authentication is the most effective control for the scenario because it directly addresses who is using the public computers:

User Identification: Authentication requires users to identify themselves (e.g., library card, login credentials) before accessing the computers. This links actions to specific individuals, making it easier to control unauthorized activity.

Policy Enforcement: Combined with other controls (e.g., content filtering), authentication enables the library to implement policies restricting downloads. If users violate the policy, their identities can be used for consequences.

Deterrent: Knowing they can be identified discourages users from attempting illegal downloads.