Scenario practice questions

Policy Audit

Why it fails: Policy Audit logs show changes to security policies and configurations, not process execution details. It is used for compliance and change tracking, and does not help in analyzing the process lineage or network connections of a suspicious process on an endpoint.

Incident Timeline

Why it fails: The Incident Timeline displays a chronological list of events related to an incident, but it does not provide the detailed process lineage or network connections in a visual map. It is more suited for understanding the sequence of events across multiple alerts rather than the specific process execution context.

Threat Intelligence

Why it fails: Threat Intelligence provides information about known malicious indicators, such as IP addresses and file hashes, but it does not show the process lineage or network connections on the endpoint. While useful for enrichment, it does not fulfill the need to examine the full process tree and associated network activity.

NIST Cybersecurity Framework

Why it fails: The NIST Cybersecurity Framework provides guidelines for managing cybersecurity risk through functions like Identify, Protect, Detect, Respond, and Recover. It is not a threat intelligence framework and does not catalog adversary TTPs. It helps organizations structure their security programs but does not offer the granular technique-level mapping needed for prioritizing TTP-based responses.

Cyber Kill Chain

Why it fails: The Cyber Kill Chain describes the stages of a cyberattack from reconnaissance to actions on objectives. While it helps understand the attack lifecycle, it does not provide a detailed catalog of TTPs for prioritization. It is more linear and less granular than MITRE ATT&CK, making it less suitable for mapping specific observed techniques to a comprehensive knowledge base.

Diamond Model

Why it fails: The Diamond Model is a framework for analyzing intrusions by examining the relationships between adversary, capability, infrastructure, and victim. It is useful for strategic analysis but does not offer a structured list of TTPs. Without a detailed technique catalog, it cannot directly support prioritization of response based on specific TTPs.

Threat intel feeds were not integrated with the case management system, so the hash was unknown at triage time.

Why it fails: The scenario says threat intel confirmed the hash three days later, not that the feed was missing. Even with perfect intel integration, unknown or zero-day droppers will not be flagged at first sight. The real gap is that the playbook closed the case without verifying persistence removal, not that the SOC lacked enrichment data at triage.

The SOC's shift-handover process did not escalate the incident to a senior analyst within the required SLA window.

Why it fails: No SLA breach or handover failure is described. The incident was handled automatically and closed by the playbook, not left waiting in a queue. Escalation timing is irrelevant here because the root cause is an inadequate closure criterion inside the automated playbook, not a human handover or escalation delay.

The endpoint agent failed to report the quarantine action to Cortex XDR, so the incident record is incomplete.

Why it fails: The scenario states the incident was auto-closed by the playbook after quarantine, meaning the agent did report the action successfully. The failure is not telemetry loss but an incomplete closure decision. If reporting had failed, the playbook would not have been triggered to close the incident, so this distractor misidentifies where the process broke.

Use a 'Manual' task; the analyst manually enters the required hash and the script's output must be manually copied into the incident context.

Why it fails: A Manual task requires human intervention and is used for decision points or data entry, not for automated script execution. It cannot automatically run a Python script or parse data. Manual tasks are unsuitable when the goal is to automate parsing of an attachment hash without user input.

Use a 'Command' task; the script must be integrated as a command in an integration, and the output is automatically mapped to incident fields without additional configuration.

Why it fails: A Command task runs a command from an integration, not a standalone Python script. While an integration could house the script, this requires developing and installing a custom integration, which is more complex than using a Script task. Additionally, outputs are not automatically mapped to incident fields; they must be configured in the task's outputs.

Use a 'Conditional' task; the script is embedded in the task's condition expression, and the output is stored in the incident's custom fields automatically.

Why it fails: A Conditional task evaluates conditions based on existing context data; it does not execute scripts. While conditions can use script-like expressions, they cannot run arbitrary Python code or return complex dictionaries. The described functionality requires a Script task, not a Conditional task.

Quarantine the file using the 'Quarantine File' action

Why it fails: Quarantining a file moves the artifact into a protected location so it cannot execute again, but it does nothing to the live network connection the malware already established. The endpoint would still be beaconing to the C2 server, so this action fails the scenario's primary requirement of stopping outbound C2 traffic.

Block the C2 IP address using a Cortex XDR IOC rule

Why it fails: An IOC block rule prevents communication with that specific indicator, but attackers frequently rotate C2 domains and IPs, and the block may take effect only on future connections. It also does not prevent the compromised host from reaching other attacker infrastructure, making it insufficient as the sole containment action here.

Terminate the suspicious process with the 'Kill Process' action

Why it fails: Killing the malicious process only removes the running instance; the attacker's persistence mechanism or scheduled task can simply restart it, and the endpoint remains free to communicate with the C2 server. This action does not satisfy the requirement to halt network communication while continuing remote forensic collection on the host.

In the task's 'Inputs' tab, map the prior task's status to a required input field of the current task.

Why it fails: The Inputs tab is used to map data from context or prior tasks into the inputs of the current task's script or integration. It does not control whether the task runs; it only supplies data. Mapping status here would not conditionally prevent or allow task execution based on that status.

In the playbook settings, enable 'Run only on task failure' and select the prior task.

Why it fails: Playbook settings do not include a global 'Run only on task failure' option tied to a specific prior task. Conditional execution is handled per task via conditions, not through a playbook-wide setting. This option describes a nonexistent feature and would not achieve the required behavior.

In the task's 'Advanced' tab, set the 'Run Condition' to 'Failed' and reference the prior task by name.

Why it fails: The Advanced tab contains settings like task timeouts and retry logic, but not a 'Run Condition' field for referencing prior task statuses. While some task properties exist there, conditional execution based on another task's status is configured in the Conditions tab, not Advanced.