Scenario practice questions

Avalanche effect

Why it fails: The avalanche effect refers to a small change in input causing a drastic change in output. While important for hash functions, it is not the property directly relied upon for integrity verification using a provided hash.

Collision resistance

Why it fails: Collision resistance ensures that it is hard to find any two different inputs that hash to the same value. However, in this scenario, the attacker is given the original hash and must find a different file with that hash, which is second pre-image resistance. Collision resistance is a stronger property but not specifically required.

Pre-image resistance

Why it fails: Pre-image resistance ensures that given a hash, it is hard to find any input that produces it. However, in this scenario, the analyst already has the original file's hash and is comparing computed hash to that. Pre-image resistance is about reversing the hash, not about finding a different input with the same hash. Second pre-image resistance is the correct property.

ARP spoofing

Why it fails: ARP spoofing forges ARP replies to associate an attacker MAC with a victim IP for interception, and it does not consume DHCP lease addresses. It would fit a man-in-the-middle scenario on the local subnet, not pool exhaustion through spoofed DHCP requests.

DNS poisoning

Why it fails: DNS poisoning corrupts resolver cache entries to redirect name lookups, which has no bearing on DHCP lease allocation. It would be correct if clients were being sent to malicious domains, but the described mechanism is address-pool depletion, which is DHCP starvation.

DHCP spoofing

Why it fails: DHCP spoofing is a rogue server issuing false leases to redirect clients, not exhaustion of the legitimate pool. It would be the answer if clients received attacker-supplied gateway or DNS settings; here the mechanism is mass request consumption, which is starvation.

DNS poisoning

Why it fails: DNS poisoning corrupts name-resolution records so queries return attacker-controlled addresses; it operates at the application layer, not by forging ARP replies that bind a MAC to a legitimate host's IP. It is tempting because both redirect traffic, but DNS poisoning would be correct if the attacker altered resolver cache entries rather than ARP tables.

DHCP spoofing

Why it fails: DHCP spoofing involves a rogue server issuing falsified IP configuration, not forging ARP replies to bind a MAC to a victim's IP. It is tempting because both are Layer 2 attacks that redirect traffic on a subnet, but DHCP spoofing would be correct only when the attacker supplies a malicious default gateway or DNS server via DHCP.

MAC flooding

Why it fails: MAC flooding overflows a switch's CAM table so traffic is flooded to all ports; it does not forge ARP bindings between a victim's IP and the attacker's MAC. It is tempting because both are Layer 2 attacks, and would be correct if the stem described CAM table exhaustion.

Enable signature-based detection on the IDS

Why it fails: Signature-based IDS matches known attack patterns in network traffic, so it cannot correlate repeated authentication failures against one account from a single source. It is tempting because signatures excel at detecting known exploits and malware payloads, but detecting brute-force login patterns requires the SIEM's threshold or correlation rule on authentication logs.

Implement a host-based IDS on the server

Why it fails: A host-based IDS monitors file integrity and local system events on the server, not the pattern of failed logins arriving from a remote IP, so it would not surface this brute-force attempt. It is tempting because HIDS detects local compromise indicators, which suits scenarios involving file tampering or rootkit activity on the host.

Increase log retention to 1 year

Why it fails: Extending retention preserves logs for later forensic review but generates no alert when the failed logins occur, leaving the SIEM silent. It is tempting because longer retention supports compliance and historical investigations, and would be correct where the requirement is post-incident evidence preservation rather than real-time detection.

Data handling policy

Why it fails: A data handling policy governs classification, storage and transmission of information, not who may connect remotely; the unauthorised foreign login breached the remote access policy. Tempting because both concern access controls, but data handling addresses information protection rather than connection authorisation.

Password policy

Why it fails: A password policy governs credential complexity, rotation and lockout, not login origin or authorisation; the foreign 3:00 AM login breached the remote access policy. Tempting because compromised credentials often enable such logins, but nothing here indicates a password rule was broken.

Acceptable use policy (AUP)

Why it fails: An AUP governs acceptable employee behaviour, not remote-access authorisation; the login breached the remote access policy defining who may connect externally. Tempting because AUPs cover misuse of company systems, but they do not specify permitted connection methods or locations.

Role-Based Access Control (RBAC)

Why it fails: RBAC grants permissions through assigned job roles, not by comparing a subject's clearance against an object's classification label. It is tempting because RBAC efficiently manages access for large groups with stable job functions, and would be correct if permissions derived from organisational roles rather than data sensitivity levels.

Discretionary Access Control (DAC)

Why it fails: DAC grants access through object owner discretion, recorded in access control lists, with no comparison of subject clearance against object classification. The mandatory lattice of clearance and classification labels is enforced by MAC, where the system, not the owner, decides access.

Attribute-Based Access Control (ABAC)

Why it fails: ABAC evaluates attributes and policy conditions at request time, but it does not inherently enforce a mandatory clearance-versus-classification lattice. That strict hierarchical comparison is MAC's defining mechanism; ABAC would be chosen for fine-grained, context-driven policies using many attributes.

The DROP rule does not apply to SSH.

Why it fails: The DROP rule matches by port or protocol; if SSH traffic still passes, the rule likely sits after an earlier ACCEPT, or matches a different port, protocol or chain than the SSH packets traverse. A DROP rule targeting SSH would block it when correctly ordered and matched.

The DROP rule is misconfigured with wrong source.

Why it fails: A wrong source in the DROP rule would leave SSH unmatched, but the exhibit's rule matches the analyst's traffic, so this does not explain the observed allow. Source-scoped DROP rules are the right choice when blocking a specific host or subnet rather than all SSH.

The default policy allows traffic, overriding the DROP rule.

Why it fails: A default ACCEPT policy only applies when no rule matches; the SSH packet still traverses the INPUT chain, so a matching DROP would take effect. The real cause is rule ordering or interface/source mismatch. Default policies are correctly set to DROP as a hardening baseline, which is why this distractor appeals.

MAC with Biba model

Why it fails: Biba enforces integrity, permitting reads of equal or higher integrity and writes to equal or lower integrity — the inverse of the stated rules. It is tempting because it also uses labels, but it would be correct for preventing integrity contamination, not the confidentiality policy described.

DAC with owner-based permissions

Why it fails: DAC grants access through object-owner discretion, not sensitivity labels compared against clearance levels. It is tempting because owners can still assign permissions, but it would be correct where flexible, owner-controlled sharing is required rather than the mandatory lattice rules described.

RBAC with role hierarchy

Why it fails: RBAC assigns permissions through roles and hierarchy, not through comparing subject clearance against object sensitivity labels. It is tempting because roles simplify administration, but it would be correct where job-function-based access is required rather than the mandatory label comparison described.

Availability

Why it fails: Availability ensures timely and reliable access to data and systems; it does not conceal content in transit. Confidentiality is the goal addressed by encryption protocols such as IPsec or TLS between the branch offices. Availability would be the correct answer if the requirement were uptime, redundancy or resilience against denial-of-service rather than secrecy.

Non-repudiation

Why it fails: Non-repudiation proves a party performed an action, typically via digital signatures, and does nothing to conceal data contents. It is tempting because signatures also use cryptography, and would be correct where the requirement is proving origin or preventing denial of a transaction, not confidentiality.

Integrity

Why it fails: Integrity detects unauthorised modification through hashes or MACs, but leaves plaintext readable, so interception still exposes contents. It is tempting because both are cryptographic goals, and integrity would be correct where the requirement is detecting tampering rather than preventing disclosure.

The application uses unsanitized input in SQL queries.

Why it fails: SQL injection manipulates database queries, not the shell, so it cannot execute OS commands on the web server. It is tempting because unsanitised input in SQL queries is a genuine, common flaw, and would be the correct root cause if the penetration tester had extracted or altered database records instead.

The application reflects user input in HTTP responses without escaping.

Why it fails: Reflecting unescaped input produces cross-site scripting in a victim's browser, not server-side command execution. It is tempting because reflected input is a genuine PHP flaw, and would be the correct root cause if the penetration tester had demonstrated script execution in another user's session rather than commands on the web server.

The application uses hidden form fields to store session tokens.

Why it fails: Hidden form fields storing session tokens enable token tampering and session hijacking, not command execution on the host. It is tempting because hidden fields are a real client-side weakness, and would be the correct root cause if the attacker had escalated privileges by editing a token value in the submitted form.

Kerberos

Why it fails: Kerberos issues binary tickets over TCP/UDP, not XML assertions, so it cannot exchange the described SAML-style data between identity and service providers. It is tempting because Kerberos is a genuine SSO protocol, and would be correct for Windows domain single sign-on using a Key Distribution Centre and ticket-granting tickets.

OAuth 2.0

Why it fails: OAuth 2.0 conveys authorisation as JSON access tokens over HTTPS, not XML assertions, and delegates access rather than authenticating the user to the service provider. It is tempting because OAuth 2.0 underpins many SSO deployments, and would be correct when an application needs delegated API access without asserting user identity.

OpenID Connect

Why it fails: OpenID Connect carries identity data as signed JSON Web Tokens over REST, not XML assertions, so it does not match the described exchange. It is tempting because OpenID Connect is a genuine SSO protocol layered on OAuth 2.0, and would be correct for modern web or mobile single sign-on using JWT ID tokens.

Risk remediation by changing all user passwords

Why it fails: Changing passwords does not stop the source IP from continuing its attempts, and risks locking out legitimate users. It is tempting because credential compromise is a real concern, and password rotation would be correct after confirming an account was actually breached, not during an active brute-force burst from one address.

Risk transfer

Why it fails: Risk transfer shifts financial impact via insurance or contracts; it cannot block an in-progress brute-force attack against live accounts. It is tempting because transfer is a legitimate strategy for residual breach costs, and would be correct when insuring against losses after controls are already in place.

Risk acceptance

Why it fails: Acceptance documents the risk and takes no action, leaving the brute-force attempts to continue unchecked. It is tempting because acceptance is valid for low-impact risks within tolerance, and would be correct for a single occasional failed login, not a sudden multi-account spike from one IP.

OAuth 2.0

Why it fails: OAuth 2.0 issues JSON access tokens for API authorisation, not XML assertions carrying authentication claims. It is tempting because OAuth 2.0 underpins many federated flows, but the XML assertion described is SAML 2.0, which is the correct standard when an IdP posts a signed XML assertion to an SP.

OpenID Connect (OIDC)

Why it fails: OIDC carries identity claims in JSON Web Tokens, not XML assertions, so it does not match the described flow. It is tempting because OIDC also federates identity between an IdP and an SP; it would be correct when tokens are signed JWTs delivered over REST endpoints.

Kerberos

Why it fails: Kerberos uses ticket-based symmetric-key exchanges within a realm, not XML assertions sent between an IdP and an SP. It is tempting as another authentication protocol, but it would be correct for domain logon within a Windows environment rather than cross-domain web federation.

Relying Party

Why it fails: The relying party is the partner domain that consumes and trusts the home domain's authentication assertion; the home domain acts as the identity provider. It is tempting because the partner trusts the assertion, and would be correct if the question asked about the partner domain's role.

Service Provider (SP)

Why it fails: The service provider is the partner domain consuming assertions, not the home domain issuing them. Here the home domain authenticates the user and asserts identity, making it the identity provider. SP is tempting because it accurately describes the resource-holding party, but the stem asks about the authenticating domain's role.

Kerberos Distribution Center (KDC)

Why it fails: A KDC issues Kerberos tickets within a single realm; it does not assert identity across organisational boundaries. Federation requires the home domain to act as the identity provider, issuing signed assertions the partner consumes. KDC is tempting because it authenticates users centrally, but that is intra-domain SSO, not cross-domain trust.

Mandatory Access Control (MAC)

Why it fails: MAC enforces access based on security labels and clearances, which satisfies the mandatory confidentiality rule. However, MAC does not permit discretionary sharing by resource owners; all access is governed by system policy. Since the scenario requires owners to grant access discretionarily, MAC alone fails to meet that requirement.

Discretionary Access Control (DAC)

Why it fails: DAC allows resource owners to grant access at their discretion, satisfying the sharing requirement. However, DAC cannot enforce a mandatory rule that overrides owner intent, such as preventing access to Confidential documents by users lacking clearance. Because the mandatory rule must be enforced regardless of owner decisions, DAC alone is insufficient.

Role-Based Access Control (RBAC)

Why it fails: RBAC assigns permissions based on organizational roles rather than individual owner discretion. While it can enforce clearance-like restrictions through role assignments, it does not natively support discretionary sharing where owners grant access to specific users. The requirement for owner-controlled sharing is not met by RBAC alone, making it unsuitable for this combined scenario.

SYN flood

Why it fails: A SYN flood exhausts TCP connection state by sending many half-open SYN packets; it never sends ARP replies. It would be correct if the symptom were a service refusing new connections, whereas one MAC claiming multiple IP addresses indicates ARP cache poisoning via forged replies.

DNS poisoning

Why it fails: DNS poisoning corrupts name-resolution records, redirecting hostnames to attacker-controlled IPs; it operates at the DNS layer, not by broadcasting ARP replies. It would fit if users were reaching fraudulent websites, but the observed one-MAC-to-many-IP ARP mapping indicates ARP spoofing.

DHCP starvation

Why it fails: DHCP starvation exhausts a server's address pool by flooding DHCPDISCOVER requests with spoofed MAC addresses; it does not forge ARP replies binding one MAC to many IPs. It would be the answer if clients were failing to obtain leases, not if ARP mappings were being poisoned.

Need-to-know

Why it fails: Need-to-know restricts access to information strictly required for a task; the developer legitimately needs database data, so that principle is not breached. Separation of duties is violated because one person both develops and deploys changes, bypassing the required independent review and deployment by a separate team.

Job rotation

Why it fails: Job rotation periodically moves staff between roles to detect fraud and reduce collusion risk; it does not require a second team to review and deploy changes. Separation of duties is the control breached, since the developer both writes and deploys changes to production databases without independent review.

Least privilege

Why it fails: Least privilege limits each account to the minimum rights needed, and the developer's access may still be minimal. The violation is separation of duties: the same person performs development and production deployment, so no independent review occurs. Least privilege concerns permission scope, not splitting a transaction between two people.

Migrate all cloud assets back on-premises

Why it fails: Migrating cloud assets on-premises abandons the operational model rather than closing the plan gap, and is disproportionate to a documentation deficiency. It would suit an organisation deliberately reversing a cloud strategy, not one whose incident response plan simply omits cloud procedures.

Retrain the IR team on cloud incident response

Why it fails: Retraining staff addresses human awareness, but the finding is that the plan itself lacks cloud procedures, so the document must be updated first. Retraining is the right action when personnel follow an adequate plan incorrectly, not when the plan omits an entire asset class.

Create a separate cloud incident response plan

Why it fails: Creating a separate cloud incident response plan fragments the response process, introducing coordination overhead between two plans during a hybrid incident. This fails the scenario because the real incident exposed that the existing plan lacked cloud coverage, so the correct action is to integrate cloud-specific procedures into the single plan to ensure unified command and consistent playbooks. It is tempting because separate plans are appropriate when cloud and on-premises environments operate under distinct regulatory frameworks or have entirely independent security teams, making isolation the correct choice in that context.

Dynamic NAT

Why it fails: Dynamic NAT maps each inside local address to a distinct inside global address from a pool, so hosts never share one address. The exhibit shows many-to-one translation distinguished by port numbers, which is PAT (NAT overload). Dynamic NAT would be correct when a pool of public addresses is rotated among internal hosts without port multiplexing.

Static NAT

Why it fails: Static NAT creates a fixed one-to-one mapping between a single inside local address and a single inside global address, so no sharing occurs and port numbers are irrelevant. The exhibit's many-to-one translation with distinct ports is PAT. Static NAT is correct when an internal server must be reachable at a permanent, predictable public address.

Port forwarding

Why it fails: Port forwarding maps one inbound port on a public address to one internal host's port, typically for publishing a service; it does not translate outbound sessions from many hosts onto a single address. The exhibit's many-to-one outbound translation with distinct source ports is PAT. Port forwarding suits inbound access to a specific internal server.

Requiring all file transfers to use SFTP instead of HTTPS.

Why it fails: SFTP secures data in transit, yet the breach occurred because credentials were guessed at authentication, so the transport protocol change leaves that vector open. It is tempting because SFTP is a legitimate hardening measure, and it would be correct where interception of transfers is the identified risk.

Implementing file-level encryption with keys stored on-premises.

Why it fails: Encrypting files at rest with on-premises keys protects stored data, but the attacker authenticated successfully with a guessed password, so decryption still occurs and documents remain readable. It is tempting because key custody limits provider access, and it would be correct where the threat is unauthorised storage access or insider disclosure.

Configuring the service to use a custom domain certificate.

Why it fails: A custom domain certificate only changes the hostname presented to users and validates the TLS endpoint; it does not strengthen authentication, so guessed passwords still succeed. It is tempting because certificates address trust and spoofing concerns, and it would be correct where users must verify they are connecting to the genuine service.