Scenario practice questions

Recovery Point Objective (RPO)

Why it fails: Recovery Point Objective (RPO) defines the maximum acceptable amount of data loss, measured in time, that an organization can tolerate following a disruption or outage. It determines the point in time to which data must be recovered, meaning any data created or modified after that specific point would be irretrievably lost. Unlike RTO, which focuses on system availability and operational uptime, RPO specifically addresses data integrity and the permissible window for data loss.

Mean Time to Repair (MTTR)

Why it fails: Mean Time to Repair (MTTR) is an operational metric that calculates the average time required to diagnose, repair, and restore a failed system or component to full functionality. While it indicates the efficiency of an organization's maintenance and incident response processes, MTTR is an average measurement of actual repair times, not a pre-defined maximum acceptable downtime established during business continuity planning. It reflects historical performance rather than a forward-looking objective for recovery.

Mean Time Between Failures (MTBF)

Why it fails: Mean Time Between Failures (MTBF) is a reliability metric that represents the predicted elapsed time between inherent failures of a system during normal operation. It quantifies the expected operational uptime of a system before it fails again, indicating its reliability and expected lifespan. MTBF is primarily used for maintenance scheduling, assessing system robustness, and predicting component longevity, but it does not define the maximum acceptable period of unavailability after a failure occurs.

Service Level Agreement (SLA)

Why it fails: A Service Level Agreement (SLA) is a contractual agreement between a service provider and a customer that formally defines the level of service expected, including metrics like uptime, performance, and support response times. While an SLA might contain clauses related to recovery objectives and penalties for non-compliance, it is fundamentally a legal document outlining service expectations and commitments, not a specific technical metric like maximum acceptable downtime itself. It represents the agreed-upon service commitment.

Network segmentation

Why it fails: Network segmentation logically divides a network into smaller, isolated segments, limiting lateral movement and the scope of a breach. While it can contain an attacker's reach by restricting access to certain network zones, it does not inherently encrypt data in transit within a segment. An attacker who gains access to a specific segment can still intercept and read unencrypted traffic flowing within that segment.

Intrusion prevention system (IPS)

Why it fails: An Intrusion Prevention System (IPS) actively monitors network traffic for malicious activity, known attack signatures, or anomalous behavior, and can block or drop suspicious packets in real-time. While an IPS can prevent certain active attacks from succeeding or alert administrators to threats, its primary function is not data encryption. It cannot prevent a passive attacker from simply sniffing and capturing unencrypted data that successfully traverses the network.

Strong password policies

Why it fails: Strong password policies enforce complexity, length, and regular rotation requirements for user authentication credentials, aiming to prevent unauthorized access to systems and accounts. These policies are crucial for identity and access management, protecting against brute-force or dictionary attacks. However, they do not provide any protection for data once it is transmitted across the network, as they do not encrypt the data itself against interception.

Scenario-based risk analysis with ordinal scales

Why it fails: Scenario-based risk analysis with ordinal scales involves identifying potential risk events and evaluating their impact and likelihood using non-numerical, ranked categories such as 'low,' 'medium,' or 'high.' While this method helps in understanding and prioritizing risks within specific contexts, it does not assign precise monetary values to potential losses. Therefore, it is unsuitable for directly estimating the financial impact required for detailed cost-benefit analysis or budget allocation.

Qualitative risk analysis using high/medium/low ratings

Why it fails: Qualitative risk analysis, by its very nature, categorizes and prioritizes risks using descriptive terms like 'high,' 'medium,' or 'low' for likelihood and impact, often represented in a risk matrix. This approach provides a subjective, relative understanding of risk severity and helps in initial screening and communication. However, it deliberately avoids assigning specific numerical or financial values to potential losses, making it incapable of producing the monetary estimates needed for quantitative financial planning.

Benchmarking against industry standards

Why it fails: Benchmarking against industry standards is a comparative process where an organization evaluates its security controls, practices, or posture against those of peer organizations or established best practices. While valuable for identifying gaps, improving security maturity, and demonstrating due diligence, it is not a direct risk analysis methodology designed to calculate specific financial losses for an organization's unique assets and threat landscape. It provides context for improvement, not a monetary loss estimate.

Bell-LaPadula

Why it fails: The Bell-LaPadula model is primarily concerned with confidentiality, preventing unauthorized disclosure of information. It enforces two main rules: the Simple Security Property (no read up) and the *-Property (no write down). These rules ensure that information flows only from lower to higher classification levels, thereby protecting sensitive data from being accessed by subjects at lower security levels, which is the inverse of an integrity requirement.

Graham-Denning

Why it fails: The Graham-Denning model is a foundational access control matrix model that defines a set of eight primitive protection rights or operations. These operations describe how subjects can create or delete subjects and objects, and how they can grant, delete, or transfer access rights. It provides a framework for specifying and managing access control policies, but it does not inherently enforce specific integrity or confidentiality rules like 'no write up' or 'no read down'.

Clark-Wilson

Why it fails: The Clark-Wilson model focuses on maintaining data integrity through well-formed transactions and separation of duties. It uses certification rules and integrity verification procedures to ensure that data items are modified only by authorized transformation procedures, which are executed by authorized users. This model distinguishes between constrained data items (CDIs) and unconstrained data items (UDIs) to enforce strict controls over data modification, aiming to prevent fraud and errors rather than protecting against information flow in a lattice-based manner.

Covert channel

Why it fails: A covert channel is a method for an entity to transfer information in a manner that violates the system's security policy but is not designed for information transfer. These channels exploit legitimate system resources, such as file locks or CPU timing, to surreptitiously communicate data between processes that are not supposed to interact. While they leak information, the question describes an application allowing a user to do something, which typically points to an authorization or race condition flaw, not a hidden communication path.

Buffer overflow

Why it fails: A buffer overflow occurs when a program attempts to write data to a fixed-size memory buffer, but the input data exceeds the buffer's capacity. This excess data then overwrites adjacent memory locations, potentially corrupting data, altering program control flow, or executing arbitrary code. The scenario described, where an application "allows a user" to perform an action, typically indicates a logical flaw in authorization or state management, not a memory boundary violation.

Side-channel attack

Why it fails: A side-channel attack involves extracting sensitive information by observing the physical implementation of a cryptosystem or other secure computation, rather than directly attacking the algorithm itself. Attackers analyze characteristics such as power consumption, electromagnetic emissions, acoustic emanations, or execution timing to infer secret keys or data. The question describes a direct application vulnerability where a user is "allowed" an action, which is a logical flaw, not an inference based on physical characteristics.

Biba model

Why it fails: The Biba model is an integrity-focused access control model, contrasting directly with confidentiality models like Bell-LaPadula, and is not suitable when confidentiality is the primary concern. Its primary goal is to prevent data corruption by enforcing two key rules: the "simple integrity property" (no read down), which prevents subjects from reading data at a lower integrity level, and the "*-integrity property" (no write up), which prevents subjects from writing to a higher integrity level. This ensures that high-integrity data is not contaminated by low-integrity data, making it suitable for systems where data accuracy is paramount.

Brewer-Nash model

Why it fails: The Brewer-Nash model, also known as the Chinese Wall model, is designed to prevent conflicts of interest by dynamically adjusting access permissions based on a subject's prior access history. It ensures that a user who has accessed information related to one client or company cannot subsequently access information related to a competing client or company within the same conflict-of-interest class. This model is distinct from classification-based models as it focuses on ethical separation and preventing information flow between competing entities, rather than strict hierarchical confidentiality levels.

Clark-Wilson model

Why it fails: The Clark-Wilson model is an integrity model specifically tailored for commercial applications, emphasizing well-formed transactions and separation of duties to maintain data consistency and prevent fraud. It uses constrained data items (CDIs) that can only be modified by certified transformation procedures (TPs), which are subject to integrity verification procedures (IVPs) and certification rules. This robust framework ensures that data integrity is preserved through controlled operations, preventing unauthorized or erroneous modifications in business processes.

MAC

Why it fails: Mandatory Access Control (MAC) is a highly structured access control model where the operating system or security kernel enforces a system-wide security policy. Access decisions are based on security labels assigned to subjects (users/processes) and objects (files/resources), representing their classification and clearance levels. Data owners have no discretion to grant or revoke access; all permissions are centrally managed and strictly enforced by the system, preventing unauthorized information flow. This model prioritizes confidentiality and integrity in high-security environments.

RBAC

Why it fails: Role-Based Access Control (RBAC) grants permissions based on a user's assigned role within an organization, rather than individual identity or object ownership. Permissions are defined for specific roles (e.g., "Administrator," "Auditor," "User"), and users acquire those permissions by being assigned to one or more roles. While administrators manage role assignments, individual data owners do not have the authority to directly grant or revoke access to their data; access is determined by the roles a user holds and the permissions associated with those roles.

ABAC

Why it fails: Attribute-Based Access Control (ABAC) makes access decisions dynamically by evaluating a set of attributes associated with the subject (user), object (resource), action (what is being done), and environment (context). A policy engine evaluates these attributes against defined policies to determine access. While ABAC offers highly granular and flexible control, the decision-making logic is based on predefined policies and attribute values, not the direct discretionary authority of a data owner to grant or revoke specific permissions on a per-user basis.

Use

Why it fails: Using customer data involves active processing, such as accessing, modifying, or analyzing it for business operations. While essential during the data's active lifecycle, 'use' does not represent the final disposition required by a retention policy once the specified period has expired. This action pertains to ongoing utility, not the mandated elimination of data.

Share

Why it fails: Sharing customer data involves transmitting or disclosing it to internal or external parties, often for collaborative purposes or service delivery. This action is a form of data transfer or disclosure that occurs during the data's operational phase, not the terminal phase where data must be permanently removed. Sharing extends data's reach rather than fulfilling a destruction requirement.

Archive

Why it fails: Archiving customer data involves moving it to long-term, often less accessible, storage for compliance, historical record-keeping, or future reference. While archiving preserves data for an extended period, it is a storage method, not a destruction method. Destruction is the subsequent, final step that occurs *after* the archiving and retention periods have both concluded, rendering the data unrecoverable.

Medium

Why it fails: The qualitative risk analysis matrix likely defines 'Medium' risk for scores falling within a specific intermediate range, typically below the threshold for 'High' risk. Since the score of 20 significantly exceeds the threshold of 15, which is established as the lower bound for 'High' risk, classifying it as 'Medium' would be incorrect. This score clearly falls into a higher risk category according to the matrix's established criteria.

Critical

Why it fails: In this specific qualitative risk analysis matrix, 'High' is explicitly defined as the top-tier risk level, indicating the most severe category. Therefore, a 'Critical' risk classification does not exist as a distinct, higher severity level within the framework utilized by this company. Assigning 'Critical' would contradict the established highest qualitative designation of 'High' for any risk exceeding the defined threshold.

Low

Why it fails: A 'Low' risk classification in a qualitative risk analysis matrix is typically reserved for scores that fall significantly below the thresholds for 'Medium' and 'High' risks, representing minimal potential impact or likelihood. Given that the assessed risk score of 20 is substantially above the threshold of 15, which is the minimum for 'High' risk, it cannot be accurately categorized as 'Low'. This score clearly indicates a much greater level of concern than what 'Low' risk implies.

Data masking

Why it fails: Data masking involves replacing sensitive, real data with realistic but fictitious data, typically for non-production environments like testing, development, or training. While it preserves the data's format and referential integrity, allowing applications to function correctly, its primary purpose is to prevent the exposure of actual sensitive information rather than to enable privacy-preserving statistical analysis through noise injection. It focuses on substitution to create safe copies, not on mathematically guaranteed privacy for aggregate queries.

Tokenization

Why it fails: Tokenization is the process of replacing sensitive data elements with non-sensitive substitutes, known as tokens, which are typically randomly generated values. These tokens bear no mathematical or algorithmic relationship to the original data, making it extremely difficult to reverse-engineer the original value from the token. This technique is primarily used to reduce the scope of compliance requirements, such as PCI DSS, by ensuring sensitive data is not stored or processed directly, but it does not involve adding noise for privacy-preserving analytics.

Anonymization

Why it fails: Anonymization involves removing or obscuring direct and indirect identifiers from a dataset to prevent the re-identification of individuals. Techniques include generalization (e.g., replacing exact age with age range), suppression (removing specific records or fields), and pseudonymization (replacing direct identifiers with pseudonyms). While it reduces re-identification risk, traditional anonymization often sacrifices data utility and does not offer the strong, quantifiable privacy guarantees against sophisticated inference attacks that differential privacy provides through the addition of noise.

Circuit-level gateway

Why it fails: Circuit-level gateways function at the session layer (OSI Layer 5), establishing a virtual circuit between the internal and external hosts. Their primary role is to validate the TCP three-way handshake to ensure the legitimacy of session establishment. While they act as a proxy, they do not perform deep inspection of the packet payload or extensive analysis of individual packet headers beyond the initial connection parameters, focusing instead on session integrity.

Application gateway

Why it fails: Application gateways, also known as proxy firewalls, operate at the application layer (OSI Layer 7) and act as an intermediary for specific application protocols. They terminate the client's connection, inspect the application-layer data for malicious content or policy violations, and then establish a separate connection to the destination server. This deep content inspection provides the highest level of security but can introduce latency and requires protocol-specific proxies.

Stateful inspection

Why it fails: Stateful inspection firewalls maintain a state table that tracks the context of active network connections, operating primarily at the network and transport layers. Unlike stateless packet filters, they can differentiate between legitimate incoming traffic that is part of an established session and new, unsolicited connection attempts. This allows them to make more intelligent and dynamic filtering decisions based on the connection's history and state, significantly enhancing security over basic packet filtering.

Single-factor authentication

Why it fails: Single-factor authentication (SFA) relies on only one type of credential to verify a user's identity. This could be something you know (like a password), something you have (like a token), or something you are (like a fingerprint). The scenario describes using both a smart card (something you have) and a PIN (something you know), clearly exceeding the definition of SFA by combining two distinct authentication factors. Therefore, this option is incorrect as it does not align with the company's requirement.

Biometric authentication

Why it fails: Biometric authentication verifies a user's identity based on unique physiological or behavioral characteristics, such as fingerprints, facial recognition, or iris scans. While highly secure, the authentication method described in the question involves a smart card (a physical token) and a PIN (a secret code), neither of which falls under the category of "something you are." Consequently, this option is incorrect because the specified authentication mechanism does not utilize biometric data.

Single sign-on

Why it fails: Single sign-on (SSO) is an authentication scheme that enables a user to log in with a single ID and password to gain access to multiple related, yet independent, software systems. While SSO streamlines the user experience across various applications, it describes an access management capability rather than specifying the number or type of authentication factors used for the initial login. The question focuses on the authentication factors themselves, not the subsequent access to multiple systems, rendering SSO an irrelevant concept for this specific query.

Implement BGP Flowspec to rate-limit traffic to the affected prefixes.

Why it fails: BGP Flowspec is designed to distribute traffic filtering rules, such as Access Control Lists (ACLs) or rate limits, to network devices based on various traffic characteristics (e.g., source/destination IP, port). While Flowspec can mitigate the *effects* of a route leak by controlling traffic destined for leaked prefixes, it does not prevent the *advertisement* of the unauthorized routes themselves. The problematic routes would still exist in the routing tables, even if traffic to them is shaped or dropped, meaning the underlying routing issue persists.

Deploy RPKI validation across all routers.

Why it fails: Resource Public Key Infrastructure (RPKI) provides a cryptographic framework to validate the origin of BGP routes, ensuring that an Autonomous System (AS) is authorized to advertise a specific IP prefix. While RPKI is a critical long-term solution for preventing prefix hijacking and improving BGP security, its deployment involves significant infrastructure setup, including Certificate Authorities (CAs), Route Origin Authorizations (ROAs), and validator software. It is a strategic, preventative measure, not an immediate tactical solution for an ongoing route leak, and its effectiveness relies on widespread adoption by all involved ASes.

Increase the BGP hold timer on data center routers.

Why it fails: The BGP hold timer defines the maximum time a BGP router will wait for a Keepalive or Update message from a peer before declaring the session down. Increasing this timer would merely prolong the time before a router detects a peer failure, potentially delaying the detection of a legitimate network issue or a BGP session flap. It has no bearing on the content of BGP Update messages, nor does it influence which prefixes are advertised or accepted, as its function is solely related to BGP session liveness, not route policy enforcement.

LDAP

Why it fails: LDAP (Lightweight Directory Access Protocol) is primarily used for accessing and maintaining distributed directory information services, such as user accounts and group memberships within a single organization's network. While it stores identity data, it does not provide a mechanism for securely exchanging authentication or authorization assertions between disparate identity providers and service providers across different trust domains, which is the core function of identity federation.

OAuth 2.0

Why it fails: OAuth 2.0 is an authorization framework that enables a user to grant a third-party application limited access to protected resources on an HTTP service, without sharing their credentials. It focuses on delegated authorization, allowing applications to act on behalf of the user. While foundational for many modern identity systems, OAuth 2.0 itself does not define how a user's identity is verified or asserted across different security domains, which is the primary concern of an identity federation protocol.

RADIUS

Why it fails: RADIUS (Remote Authentication Dial-In User Service) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users connecting to a network service. It is primarily used for authenticating users for network access, such as VPNs or Wi-Fi, against a central directory within a single administrative domain. RADIUS does not facilitate the secure exchange of identity assertions or authentication decisions between distinct organizations or trust boundaries, which is the hallmark of identity federation.

Separation of duties

Why it fails: This principle is an administrative control designed to mitigate the risk of fraud, error, and insider threat by distributing critical tasks among multiple individuals. It ensures that no single person possesses sufficient privileges to complete a sensitive operation entirely on their own, requiring collusion to bypass controls. While vital for governance, it does not directly address the architectural layering of diverse technical security mechanisms to protect against external attacks.

Fail-secure

Why it fails: The fail-secure principle dictates that when a system component experiences a failure, it should default to a state that denies access or operation, thereby preserving the confidentiality, integrity, and availability of data. This prevents unauthorized access or exploitation during system malfunctions. However, this principle specifically addresses system behavior upon failure rather than the proactive, multi-layered deployment of diverse security mechanisms intended to prevent initial compromise.

Least privilege

Why it fails: The principle of least privilege mandates that every user, program, or process should be granted only the minimum necessary permissions and access rights required to perform its specific authorized functions. This significantly reduces the potential impact of a security breach or error by limiting the scope of damage an attacker or compromised entity can inflict. While crucial for minimizing the attack surface, it focuses on access control granularity rather than the strategic deployment of multiple, distinct security layers throughout an entire system.

Ensure data availability

Why it fails: Data masking's primary objective is data confidentiality, not availability. While masked data is available for use in non-production environments, the masking process itself does not inherently guarantee or enhance the availability of the original production data. In fact, poorly implemented masking solutions, especially those involving complex transformations or large datasets, could potentially introduce performance overheads or data integrity issues, indirectly impacting the availability of the masked data or the systems processing it.

Encrypt data at rest

Why it fails: Data masking is fundamentally different from encryption. Encryption renders data unreadable without a decryption key, allowing for reversible transformation back to its original state. In contrast, data masking permanently alters sensitive data values with fictitious but structurally similar data, making the original data largely irrecoverable from the masked version. While both aim to protect data, masking focuses on creating safe, non-production datasets, whereas encryption secures data in transit or at rest, preserving its original form for authorized access.

Simplify access controls

Why it fails: Data masking does not simplify access controls; rather, it complements them by reducing the sensitivity of data in certain environments. Access controls, such as role-based access control (RBAC) or attribute-based access control (ABAC), govern who can access what resources and under what conditions. Masking operates on the data itself, transforming it to reduce risk, but it does not alter the underlying mechanisms or complexity of managing user permissions and entitlements to systems or databases.

Maximum Tolerable Downtime (MTD)

Why it fails: The Maximum Tolerable Downtime (MTD) represents the absolute maximum period a business process or system can be inoperable before experiencing unacceptable consequences, such as severe financial losses, regulatory penalties, or irreparable reputational damage. While a critical output of the BIA, MTD defines the *limit* of survivability, not the *target* recovery time. The BIA uses MTD to establish the outer boundary within which recovery efforts must succeed, informing the more precise RTO.

Recovery Point Objective (RPO)

Why it fails: The Recovery Point Objective (RPO) specifies the maximum acceptable amount of data loss, measured in time, that an organization can tolerate for a given business function. Unlike downtime metrics, RPO focuses exclusively on data currency and integrity, determining how far back in time data must be recoverable. The BIA identifies RPO by analyzing the impact of data loss, which is distinct from the impact of system unavailability.

Service Level Agreement (SLA)

Why it fails: A Service Level Agreement (SLA) is a contractual commitment between a service provider and a customer, defining the level of service expected, including metrics like uptime, performance, and support response times. While BIA outputs like RTO and RPO can inform the development and negotiation of SLAs, an SLA itself is a formal agreement or document, not a direct objective or metric *identified* during the BIA process. The BIA determines internal business needs, which then may be reflected in external SLAs.

Clock skew between sources and SIEM

Why it fails: Clock skew primarily affects the accurate timestamping and correlation of events within a SIEM, leading to logs appearing out of sequence or making forensic analysis challenging. While it can hinder the effective use of SIEM data for incident response and anomaly detection, it does not inherently cause the physical loss or non-transmission of log events from the source systems to the SIEM. The events are still sent and received, just with potentially incorrect timestamps relative to each other.

Insufficient SIEM storage capacity

Why it fails: Insufficient SIEM storage capacity would primarily impact the system's ability to retain historical log data or index new events for search and analysis once they have been successfully received. While severe storage constraints could eventually lead to the SIEM dropping new events if its ingestion queues overflow due to an inability to write to disk, the immediate cause of events being missing during transmission from the source is not a storage capacity problem. Transmission occurs independently of the SIEM's long-term storage capabilities.

Network bandwidth saturation

Why it fails: Network bandwidth saturation can indeed lead to packet drops as network devices discard traffic when their buffers overflow, potentially impacting log transmission. However, this is a symptom of network congestion, whereas UDP packet loss is an inherent characteristic of the protocol itself, regardless of network load. While saturation can exacerbate packet loss, the fundamental unreliability of UDP makes it a more direct and consistent reason for missing events compared to a fluctuating condition like network saturation.

Measure the effectiveness of backup restoration.

Why it fails: Measuring the effectiveness of backup restoration involves actual execution of recovery procedures, verifying data integrity, and timing the recovery process against established Recovery Time Objectives (RTOs). Tabletop exercises, being discussion-based simulations, do not involve the physical activation or testing of backup systems. Therefore, they cannot provide empirical data on the technical efficacy or speed of restoration capabilities, which is better assessed through functional disaster recovery drills.

Test technical capabilities of security tools.

Why it fails: Testing the technical capabilities of security tools, such as firewalls, intrusion detection systems, or endpoint protection, requires active deployment, configuration, and observation of their performance against actual or simulated threats. Tabletop exercises are conceptual discussions about *how* tools might be used, but they do not involve the direct interaction, configuration, or performance measurement of these technical controls. Such assessments are typically conducted through technical drills, penetration tests, or red team exercises that engage the tools directly.

Identify unpatched vulnerabilities in systems.

Why it fails: Identifying unpatched vulnerabilities in systems is a technical assessment objective typically achieved through automated vulnerability scanning, patch management audits, or penetration testing. These methods involve direct interaction with systems to discover missing security updates, misconfigurations, or exploitable flaws. Tabletop exercises, conversely, focus on human processes, policies, and decision-making during an incident, rather than the technical discovery of system-level security weaknesses.

White box

Why it fails: White box testing provides the assessor with complete and comprehensive knowledge of the target environment, including full access to system architecture diagrams, network configurations, and often source code. This deep insight allows for thorough analysis of internal logic, security controls, and potential vulnerabilities that might be missed by external testing. While highly effective for detailed code review and internal security audits, it does not simulate an external attacker's perspective, which is often the primary objective for a general third-party assessment.

Grey box

Why it fails: Grey box testing involves the assessor having partial or limited knowledge of the target system, such as user-level credentials, network diagrams for specific segments, or access to internal documentation. This approach aims to simulate an attacker who has gained some initial foothold or an insider threat with restricted access. While it offers a balance between efficiency and realism by focusing on specific areas, it is not the most appropriate choice when the goal is to assess an organization's defenses from a completely unknown, external perspective, as implied by a general third-party assessment without specified knowledge.

Internal test

Why it fails: An internal test refers to an assessment conducted from within the organization's network perimeter, simulating an insider threat or an attacker who has successfully breached the external defenses. While the knowledge level for an internal test can vary (black, grey, or white box), the term primarily defines the *location* of the assessment, not the *information* provided to the tester. The question describes a third party performing an assessment without specifying location or initial knowledge, making 'black box' a more direct and common fit for evaluating external defenses from an unknown perspective.