Free CSSLP Practice Test

The process described is Perform Qualitative Risk Analysis. This is a standard project management process where identified risks are prioritized for further action. The prioritization is achieved by assessing each risk's probability of occurrence and its potential impact on project objectives. The output of this process is a ranked or grouped list of risks, which allows the project team to focus its attention on the most critical threats and opportunities. Fred's team is explicitly "assessing and combining the risks probability of occurrence and impact" to prioritize them, which is the definition of this process.

A. Risk identification: This is the process of determining which risks might affect the project and documenting their characteristics. The scenario states risks have already been "identified."
B. Risk Breakdown Structure creation: This involves creating a hierarchical decomposition of potential sources of risk. It is a tool for organizing risks, not the process of prioritizing them.
D. Perform quantitative analysis: This process numerically analyzes the effect of high-priority risks on overall project objectives. It is more in-depth and typically follows qualitative analysis.

1. Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th ed.). Section 11.3, "Perform Qualitative Risk Analysis," p. 419. The text defines this process as "prioritizing individual project risks for further analysis or action by assessing their probability of occurrence and impact as well as other characteristics."

2. National Institute of Standards and Technology (NIST). (2012). Guide for Conducting Risk Assessments (NIST Special Publication 800-30, Revision 1). Section 2.3.2, "Risk Analysis," p. 17. This section describes the analysis of risk, which involves considering "the likelihood of occurrence for the identified threats" and "the impact of the threats."

3. Goertzel, K. M., & Paza, C. (2012). Security in the Software Lifecycle. In M. Khosrow-Pour (Ed.), Software Development Techniques for Constructive Information Systems Design (pp. 316-341). IGI Global. Chapter 16, p. 326. The text discusses risk analysis within the SDLC, stating, "The first step in risk analysis is to determine the probability of the risk occurring and the impact... This is known as qualitative risk analysis."

4. Boehm, B. (1991). Software Risk Management: Principles and Practices. IEEE Software, 8(1), 32-41. https://doi.org/10.1109/52.62940. On page 34, the article discusses risk assessment, which includes the steps of risk identification, risk analysis (determining probability and loss/impact), and risk prioritization. This foundational paper aligns directly with the process described in the question.

Functional testing is a type of black-box testing that verifies a system's behavior against its specified functional requirements. The question asks to verify that the build "meets its data requirements" and "correctly generates each expected display and report." This is the core purpose of functional testing: to confirm that the software performs its intended functions accurately. It treats the software as a black box, providing inputs and checking if the outputs (displays, reports, data handling) match the expected results as defined in the requirements documentation.

A. Performance test: This non-functional test measures system attributes like speed, scalability, and stability under load, not the correctness of the data or reports generated.
C. Reliability test: This non-functional test evaluates the software's ability to operate without failure for a specified period under stated conditions, focusing on stability over time, not specific functional outputs.
D. Regression test: This test ensures that recent code changes have not negatively impacted existing functionalities. While it uses functional test cases, its primary purpose is to detect new defects in old code.

1. Official (ISC)² CSSLP CBK, 3rd Edition: Domain 7, "Secure Software Testing," Section "Types of Software Testing." The text defines functional testing as a method to "verify that the software is behaving as expected" and "is based on the functional specification of the software." This directly aligns with verifying that a build meets data requirements and generates correct reports.

2. NIST Special Publication 800-160, Vol. 2: Developing Cyber Resilient Systems: A Systems Security Engineering Approach. Appendix F, "System and Security Test and Evaluation," discusses various testing types. It implicitly supports the distinction, where functional testing (part of developmental T&E) verifies that the system meets its specified requirements, contrasting with performance or reliability testing which are non-functional.

3. Carnegie Mellon University, Software Engineering Institute (SEI): In "A Taxonomy of Testing," by Ilene Burnstein et al., functional testing is defined as testing that "ignores the internal parts and focuses on the output... according to the requirement specification." This confirms that verifying displays and reports against requirements is a functional test. (CMU/SEI-94-TR-024, Section 3.1.1).

4. University of Toronto, CSC301 "Introduction to Software Engineering" Courseware: Lecture notes on "Software Testing" distinguish between functional testing (testing against requirements) and non-functional testing (performance, usability, reliability). The material specifies that functional testing answers the question, "Does the system do what it is supposed to do?" which is precisely the scenario described.

The Annualized Loss Expectancy (ALE) is a core concept in quantitative risk analysis. It is calculated by multiplying the Single Loss Expectancy (SLE) by the Annualized Rate of Occurrence (ARO). First, the SLE is determined by multiplying the Asset Value (AV) by the Exposure Factor (EF). SLE = AV EF SLE = $600,000 0.30 = $180,000 Next, the ALE is calculated using the ARO, which is 2 (twice a year). ALE = SLE ARO ALE = $180,000 2 = $360,000 This calculation provides a monetary value for the expected annual loss from a specific threat, aiding in cost-benefit analysis for security controls.

B: This value represents the Single Loss Expectancy (SLE), the cost of a single incident, not the annualized total loss. C: This is an incorrect calculation and does not align with the standard quantitative risk analysis formulas using the provided inputs. D: This value is an incorrect calculation, likely resulting from using an erroneous Annualized Rate of Occurrence (ARO) instead of the stated value of 2.

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

Page F-3, Appendix F, Section F.2: This section explicitly defines the formulas for risk calculation: "Single Loss Expectancy (SLE) = Asset Value (AV) x Exposure Factor (EF)" and "Annualized Loss Expectancy (ALE) = Single Loss Expectancy (SLE) x Annualized Rate of Occurrence (ARO)." This directly supports the methodology used to arrive at the correct answer.

2. Carnegie Mellon University, Software Engineering Institute. (2005). A Framework for Quantitative Information Security Risk Management (CMU/SEI-2005-TN-028).

Page 11, Section 3.2.2: This technical note discusses the classic risk analysis model, stating, "The annualized loss expectancy (ALE) is the product of the ARO and the single loss expectancy (SLE)." It further defines SLE as the product of asset value and exposure factor, confirming the calculation steps.

3. Peltier, T. R. (2010). Information Security Risk Analysis, Third Edition. Auerbach Publications.

Chapter 6, "Risk Analysis Methodologies," Page 114: This academic text, widely used in university curricula, details the quantitative risk analysis process. It provides the exact formulas: SLE = Asset Value ($) x Exposure Factor (%) and ALE = SLE x Annualized Rate of Occurrence. This source validates the calculation performed. (Note: While a book, it is a foundational academic text in the field).

The described steps follow a standard penetration testing methodology, moving from passive information gathering to active scanning. After identifying active systems and their open ports/applications, the next logical phase is enumeration. Enumeration involves gathering more detailed information about the targets to identify potential vulnerabilities. Operating System (OS) fingerprinting is a crucial enumeration technique to determine the specific OS and version running on a target host. This information is fundamental for selecting appropriate exploits, as many vulnerabilities are OS-specific. While service fingerprinting is also part of enumeration, identifying the OS provides the foundational context for all services running on that system.

B. Map the network of We-are-secure Inc.: This is largely accomplished during the "Determination of network range" and "Identification of active systems" steps already completed.
C. Install a backdoor to log in remotely on the We-are-secure server.: This step belongs to the "Maintaining Access" phase, which occurs only after an initial exploit is successful and access has been gained.
D. Fingerprint the services running on the we-are-secure network.: While this is also a valid enumeration step, a common methodology is to first identify the foundational OS before analyzing the specific versions of services running on it.

1. National Institute of Standards and Technology (NIST) Special Publication 800-115, "Technical Guide to Information Security Testing and Assessment":

Reference: Section 3.3, "Discovery," page 3-5. The document outlines the discovery phase, which "can include scanning for open ports, identifying the operating system (OS) of target systems, and identifying applications and services." This confirms that OS identification is a key activity that follows the initial port scanning.

2. The Penetration Testing Execution Standard (PTES):

Reference: PTES Technical Guidelines, Section 3: "Vulnerability Analysis." The standard describes this phase as following the initial discovery/intelligence gathering. It states, "The vulnerability analysis phase of a penetration test is the process of discovering flaws in systems and applications... This is accomplished through the use of active and passive analysis of the information gathered." This analysis includes identifying the OS and specific service versions to find matching vulnerabilities. A top-down approach often prioritizes identifying the OS first.

3. Carnegie Mellon University, Software Engineering Institute (SEI), "Taxonomy of Penetration Testing" (CMU/SEI-2020-TR-003):

Reference: Section 3.2.2, "Scanning," page 11. The document describes the scanning phase, which includes port scanning, network mapping, and vulnerability scanning. It notes that tools like Nmap are used for "OS fingerprinting to determine the operating system of the target." This places OS fingerprinting as a core activity within the scanning/enumeration phase.

Risk transference is a strategy that involves shifting the negative impact of a threat, along with ownership of the response, to a third party. In this scenario, the project manager is hiring an external company to handle the hardware work. By doing so, the financial and operational risks associated with that specific part of the project (e.g., delays, defects, cost overruns) are transferred to the vendor via a contractual agreement. The project itself does not eliminate the risk but reassigns the responsibility for managing it and bearing its consequences.

A. Exploit: This is a response strategy for positive risks (opportunities), where actions are taken to ensure the opportunity is realized, not for managing a potential threat.
B. Mitigation: Mitigation involves taking active steps to reduce the probability or impact of a risk, such as implementing quality controls, not shifting the entire responsibility to another party.
D. Avoidance: Risk avoidance would mean changing the project plan to eliminate the hardware work altogether, thereby removing the risk entirely, which is not what is happening here.

1. NIST Special Publication 800-30 Revision 1, Guide for Conducting Risk Assessments. (September 2012).

Section 2.4, RISK RESPONSE, Page 21: This section defines the four primary risk response options. It defines risk sharing (transference) as: "Shifting the burden of loss or impact of a risk to another party through legislation, contract, insurance, or other means." The scenario of hiring a company via contract is a direct example of this definition.

2. Purdue University, ITaP Risk Management Methodology. (2018).

Section 4.2, Risk Treatment, Page 7: This document outlines risk treatment options, stating, "Risk Transfer: Sharing the risk with another party who is better able to manage the risk. Examples include outsourcing an activity or purchasing insurance." This directly supports the answer.

3. Boehm, B. W. (1991). Software Risk Management: Principles and Practices. IEEE Software, 8(1), 32-41.

Section: Risk Management Techniques, Page 35: While discussing risk mitigation, the paper describes risk transfer as a key technique: "The main way to transfer risks is to subcontract the risky component to a vendor with more experience in that area." This academic source validates outsourcing as a form of risk transference.

DOI: https://doi.org/10.1109/52.62930

An effective information security program is built on several foundational objectives that establish governance, define protection priorities, and manage human risk. The objectives include:
1. Security Organization (B): Establishing a formal structure with defined roles, responsibilities, and authority (e.g., a Chief Information Security Officer) is a primary objective. This ensures accountability and provides the framework for managing the entire program.
2. Information Classification (D): A core objective is to identify and classify information assets based on their sensitivity, criticality, and business value. This process is fundamental to risk management as it determines the appropriate level of protection required for different types of data.
3. Security Education (A): A continuous security education, training, and awareness (SETA) program is a critical objective. It aims to ensure that all personnel understand their security responsibilities and act in a way that upholds security policies, thereby reducing human error.

C. System classification: This is a necessary activity but is typically a subordinate step derived from the classification of the information that the system processes, stores, or transmits. It is not a primary objective of the overall program itself. ---

1. NIST Special Publication 800-100, "Information Security Handbook: A Guide for Managers" (2007).

Page 11, Section 2.2, "Elements of an Effective Information Security Program": This section outlines the essential components of a security program. It explicitly lists "An organizational structure to support the program" (supporting B. Security organization) and "An information security training and awareness program" (supporting A. Security education).

Page 26, Section 3.3.1, "Categorize information and systems": This section details the risk management process, which begins with categorizing information based on impact levels. This directly supports the necessity of D. Information classification as a foundational activity.

2. Federal Information Processing Standards (FIPS) Publication 199, "Standards for Security Categorization of Federal Information and Information Systems" (2004).

Page 1, Section 3, "Security Categorization": The standard states, "The first step in the risk management process is security categorization of information and the information system." This emphasizes that classifying information and the systems that handle it is a foundational step, with the information's characteristics driving the process, supporting D. Information classification as a primary objective.

3. Saltzer, J. H., & Schroeder, M. D. (1975). "The Protection of Information in Computer Systems." Proceedings of the IEEE, 63(9), 1278-1308. (DOI: 10.1109/PROC.1975.9939).

This foundational paper on computer security, often cited in university curricula, implicitly supports the need for a Security Organization through its discussion of administrative controls and responsibility. It also underpins the concept of Information Classification by discussing the need to tailor protection mechanisms to the sensitivity of the information being protected. The principle of Psychological Acceptability relates to the need for user Security Education.

Port scanning is a fundamental reconnaissance technique used in penetration testing. It involves systematically scanning a computer's ports to identify which ones are open and listening for connections. By discovering open ports and the services running on them (e.g., web server, FTP server), an attacker can identify potential vulnerabilities. Exploiting these vulnerabilities is a primary method for gaining unauthorized access to the system and the information it contains. This technique is a direct and initial step toward the objective described in the question.

A. Biometrician: A biometrician is a statistician who applies statistical methods to biological data. This term is unrelated to penetration testing or computer security techniques.
B. Van Eck Phreaking: This is a form of eavesdropping that involves detecting and reconstructing information from the electromagnetic emissions of electronic devices like monitors. It is a passive, side-channel attack, not an active penetration technique.
D. Phreaking: This term historically refers to the practice of hacking telephone networks, primarily to make free calls or disrupt service. It is specific to telecommunications and not a general computer penetration testing method.

1. National Institute of Standards and Technology (NIST). (2008). Special Publication 800-115, Technical Guide to Information Security Testing and Assessment.

Reference for C (Port Scanning): Section 4.3, "Discovery," states, "The objective of network port and service identification is to identify open ports and services running on the target systems... This information can be used to help identify potential vulnerabilities on the target systems." (Page 4-5). This directly supports port scanning as a technique to find entry points to access a system.

2. Kuhn, M. G. (2004). Compromising emanations: Eavesdropping risks of computer displays. University of Cambridge, Computer Laboratory.

Reference for B (Van Eck Phreaking): The paper describes the technique as a process of eavesdropping on the electromagnetic emanations from video display units to reconstruct the screen content. Section 1, "Introduction," clarifies this is a form of electronic eavesdropping, not active system penetration. (Page 1).

3. Holt, T. J. (2017). Subcultural evolution? Examining the influence of crackers, phreakers, and pirates on the contemporary hacking community. Deviant Behavior, 38(1), 25-38.

Reference for D (Phreaking): This academic article defines phreaking in its historical context: "Phreaking involved the manipulation of the telephone system to acquire free long-distance service..." (Page 26). This confirms its specific application to telephony. DOI: https://doi.org/10.1080/01639625.2016.1197687

Demon dialing, more commonly known today as war dialing, is an automated technique used in penetration testing. It involves using a software program and a modem to systematically dial a large range of telephone numbers. The objective is to identify any devices, such as other modems, fax machines, or remote access servers, that answer the call. This method is highly effective for discovering unauthorized or insecure remote access points connected to an organization's telephone lines, which could serve as a backdoor into the internal network. The process is automated and specifically targets phone lines to find modems, matching the question's description perfectly.

B. Sniffing: This is a passive technique for capturing and analyzing data packets traversing a computer network, not for dialing phone lines.
C. Social engineering: This method relies on manipulating people to divulge confidential information or perform actions; it does not involve automated dialing tools.
D. Dumpster diving: This is a physical reconnaissance technique that involves searching through an organization's trash to find sensitive information.

1. National Institute of Standards and Technology (NIST) Special Publication 800-115, Technical Guide to Information Security Testing and Assessment. Section 5.5.2, "War Dialing," describes the technique: "War dialing is the process of dialing a range of phone numbers to find unprotected modems... War dialers can be configured to dial a specific range of numbers, such as all numbers assigned to a particular organization."

2. Bishop, M. (2003). What is computer security? IEEE Security & Privacy, 1(1), 67-69. https://doi.org/10.1109/MSECP.2003.1176998. This foundational article discusses various attack vectors. The concept of war dialing (demon dialing) is a classic example of an automated discovery technique used to find unauthorized entry points into a network via telephone lines, a topic central to understanding the breadth of computer security threats.

3. University of Virginia, Department of Computer Science. CS 6501: Special Topics in Computer Science - Cyber-Physical Systems Security, Lecture 2: Threat Modeling. The courseware discusses various threat vectors, including war dialing as a method for discovering unauthorized modems and remote access points that bypass primary network firewalls.

Configuration Management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. The core activities of CM include Configuration Identification, Configuration Control, Configuration Status Accounting, and Configuration Verification and Auditing. While the cost of managing configuration items is a project management concern, "Configuration Item Costing" is not a standard, defined activity within the CM process itself. CM focuses on the technical and administrative management of the configuration, not its financial valuation.

A. Configuration Identification: This is incorrect because it is a fundamental CM activity that involves selecting and uniquely identifying the configuration items (CIs) to be placed under control.
B. Configuration Verification and Auditing: This is incorrect because it is a crucial CM activity that ensures the configuration of a CI is complete, correct, and consistent with its specified requirements.
C. Configuration Status Accounting: This is incorrect because it is a core CM activity responsible for recording and reporting the status of CIs and change requests throughout the development lifecycle.

1. National Institute of Standards and Technology (NIST) Special Publication 800-128, Guide for Security-Focused Configuration Management of Information Systems. Section 2.2, "Configuration Management Process," outlines the key activities as Planning, Identification, Control, Status Accounting, and Verification and Auditing. Costing is not listed as a core process activity.

2. IEEE Std 828-2012, IEEE Standard for Configuration Management in Systems and Software Engineering. Section 5, "SCM Activities," details the required activities for SCM. These include Configuration Identification (5.2), Configuration Control (5.3), Configuration Status Accounting (5.4), and Configuration Verification and Audit (5.5). The standard does not define costing as a primary SCM activity.

3. Carnegie Mellon University, Software Engineering Institute (SEI), CMMI for Development, Version 1.3. The Configuration Management (CM) process area (page 217) specifies practices that map directly to identification, control, status accounting, and audits. Financial costing is outside the scope of this process area.

A Security Information and Event Management (SIEM) system's primary purpose is to provide a holistic view of an organization's security posture through log aggregation, correlation, and analysis. To achieve the goals of analysis, correlation, event prioritization, and response, a SIEM relies on several key features. It uses a security knowledge base (D), including threat intelligence and correlation rules, to identify significant events. Asset information (A) provides critical context to prioritize alerts based on business impact. A graphical user interface (E) with dashboards and visualizations is essential for analysts to interpret the data. Finally, features for incident tracking and reporting (C) are crucial for managing the response workflow and documenting security events for compliance and review.

B. Transmission confidentiality protection: This is a feature of the secure log transport protocol (e.g., TLS for syslog), not a core analytical or response function of the SIEM application itself.

1. NIST Special Publication 800-92, Guide to Computer Security Log Management.

Page 21, Section 4.3, Log Analysis: Discusses how SIEMs perform event correlation using rule-based or statistical methods, which relies on a security knowledge base (D). It also mentions the use of "consoles" for viewing events, which implies a graphical user interface (E).

Page 22, Section 4.4, Responding to Events: Describes the process of generating alerts and reports, which aligns with incident tracking and reporting (C).

2. Bhatt, S., Manadhata, P. K., & Zomlot, L. (2014). The Operational Role of a Security Operations Center. In Security Operations Center - SOC (pp. 11-12). Cisco Press.

This document, often used in academic and professional settings, describes SIEM capabilities. It states, "The SIEM can also be enriched with information about the assets, such as the function of the asset, its owner, and its location... This information helps the SOC analyst to quickly determine the criticality of the events." This directly supports asset information storage and correlation (A).

3. Bou-Harb, E., Debbabi, M., & Assi, C. (2014). A survey of security information and event management (SIEM) systems. IEEE Communications Surveys & Tutorials, 16(4), 2183-2207. https://doi.org/10.1109/COMST.2014.2329538

Section III.A, SIEM Features: This peer-reviewed survey explicitly lists key SIEM features, including "Dashboards and Visualizations" (E), "Reporting" (C), and "Correlation" which relies on a knowledge base (D) of rules and threat intelligence. It also discusses the importance of data enrichment with asset and vulnerability information (A).