Detection And Reporting practice questions

Remove the causality filter entirely because null checks are unsupported in XQL.

Why it fails: Null checks (`!= null`) are fully supported and frequently used in XQL filtering.

Change 'xdr_data' to 'panw_alerts' and use 'aggregate' instead of 'comp'.

Why it fails: 'aggregate' is not the primary aggregation verb in XQL; 'stats' is standard.

Replace 'filter' with 'where' and remove the dataset declaration.

Why it fails: 'filter' is a valid XQL command, and specifying the dataset is mandatory in XQL.

dataset = panw_analytics_alerts | filter alert_name = 'WMI Execution'

Why it fails: This searches existing alerts rather than raw telemetry data, missing unalerted activity.

dataset = network_story | filter protocol = 'WMI'

Why it fails: WMI execution is a host-based process activity, not a distinct network protocol dataset.

dataset = endpoints_inventory | filter status = 'Active'

Why it fails: Endpoints inventory tracks agent deployment status and asset details, not event telemetry.

dataset = endpoints_inventory | filter owner == 'TargetUser'

Why it fails: endpoints_inventory holds asset metadata, not process or command telemetry, so it cannot show actions across a 24-hour window. It is tempting because it is user-scoped, and would be correct for auditing which endpoints a user owns rather than activity.

dataset = panw_analytics_alerts | filter alert_id == 'TargetUser'

Why it fails: panw_analytics_alerts contains alert records, not raw endpoint activity, and alert_id is not a user identifier, so the filter matches nothing meaningful. It is tempting as the alert's source dataset, and would be correct for retrieving related alerts rather than all user actions.

dataset = network_story | filter user_context == null

Why it fails: network_story covers network sessions, not endpoint command execution, and filtering user_context == null selects records lacking user attribution, the opposite of the requirement. It is tempting for tracing network activity, and would be correct for investigating connections tied to an IP.

Host Insights -> Disk Utilization report

Why it fails: The Disk Utilization report under Host Insights shows endpoint disk space usage, not licence consumption or telemetry ingestion volume. Ingestion rates and licence usage appear in the Cortex XDR management console's licence and data ingestion dashboards, so this report cannot answer the administrator's question.

Incident Response -> Queue Statistics

Why it fails: Queue Statistics reports incident queue volumes and assignment metrics, not licence consumption or ingestion rates. It is tempting because it is a monitoring dashboard, but it would be correct for tracking analyst workload and incident backlog rather than raw telemetry volume.

Analytics -> BIOC Rule Health monitor

Why it fails: BIOC Rule Health monitors detection rule execution and failures, not platform licence usage or raw endpoint telemetry ingestion. It is tempting because it is an analytics monitoring view, but it would be correct for troubleshooting why a specific BIOC rule is not firing as expected.

dataset = panw_analytics_alerts | filter source == 'AWS'

Why it fails: panw_analytics_alerts holds Cortex XDR-generated alerts, not raw CloudTrail events, so filtering source == 'AWS' queries the wrong dataset entirely. The aws_cloudtrail_raw dataset is the correct target for console login failures; this option is tempting because alert datasets do surface cloud findings.

dataset = xdr_data | filter cloud_event == 'AWS_LOGIN_FAIL'

Why it fails: The xdr_data dataset holds endpoint telemetry, not the ingested CloudTrail records, so cloud_event never appears there; the query returns nothing. It is tempting because xdr_data is the default dataset most endpoint XQL examples use, and it would be right for process or network event searches.

dataset = endpoints_inventory | filter cloud_provider == 'AWS'

Why it fails: endpoints_inventory is an asset-inventory dataset holding host metadata, not audit log events, so it cannot match individual AWS console login attempts. It tempts because it does list cloud_provider, which suits reporting which endpoints belong to AWS, not querying CloudTrail login failures.

XQL Search > Query Builder

Why it fails: Incorrect. XQL Search is used for threat hunting and running ad-hoc queries, not managing BIOC rules.

Endpoints > Policy Rules

Why it fails: Incorrect. Endpoints > Policy Rules is used for malware and exploit prevention profiles.

Data Collection > Log Stitching

Why it fails: Incorrect. Data Collection manages agent settings and custom log forwarders.

Endpoint hard disk SMART status monitoring

Why it fails: SMART monitoring tracks hardware disk health, unrelated to console user activity audits.

Automatic kernel debugging dump generation

Why it fails: Kernel debugging dumps troubleshoot agent crashes, not admin console auditing.

Set the threshold count to 5, group by event ID, and set the time window to 3 minutes.

Why it fails: Incorrect. This reverses the threshold count and time window values.

Configure a BIOC rule using a single event trigger with a recurrence limit set to 3.

Why it fails: Incorrect. Single event triggers with recurrence limits do not properly aggregate across distinct sliding time windows based on grouping keys.

Use XQL correlation rules instead, because BIOC rules cannot evaluate time-based thresholds.

Why it fails: Incorrect. BIOC rules natively support threshold and grouping capabilities.

dataset = xdr_data | filter event_type = ENUM.PROCESS and action_process_image_name = "powershell.exe" | comp count() as exec_count by agent_hostname | limit exec_count > 5

Why it fails: This is wrong because limit restricts the number of returned rows, not the values of a field. It cannot express a numeric comparison like exec_count > 5. Using limit here would simply cap the result set size and would ignore the threshold entirely, so the query would not isolate endpoints with more than five PowerShell executions.

dataset = xdr_data | filter event_type = ENUM.PROCESS and action_process_image_name = "powershell.exe" and count() > 5 | comp count() as exec_count by agent_hostname

Why it fails: This fails because a filter stage cannot reference an aggregate function like count() before comp has produced it. XQL evaluates stages sequentially, so count() is not defined at the filter stage. The query would fail to parse or return no results because the aggregation has not yet occurred, making it invalid for threshold filtering.

dataset = xdr_data | filter event_type = ENUM.PROCESS and action_process_image_name = "powershell.exe" | comp count() as exec_count by agent_hostname | where exec_count > 5

Why it fails: This is incorrect because where is not a valid XQL stage keyword for filtering aggregated results. While where is used in some other query languages, Cortex XDR XQL uses the filter stage for row-level conditions, including on aggregated fields. The query would produce a syntax or unknown-stage error, so it cannot return the intended thresholded results.

Use the Cortex XDR API to poll for new alerts and update their assignment and tags programmatically.

Why it fails: API polling is a custom solution that adds complexity and delay. It is not the intended configuration method for a BIOC rule. Native BIOC settings provide immediate assignment and tagging without external scripts, making the API approach unnecessary and error-prone.

Configure a global alert exclusion rule that matches the BIOC rule name and applies the assignment and tag.

Why it fails: Alert exclusion rules are used to suppress or exclude alerts, not to assign them or add tags. They cannot apply assignments or tags to generated alerts. Therefore, this approach does not meet the requirement and may inadvertently suppress alerts.

Create a playbook in Cortex XSOAR that assigns the alert and adds the tag when the BIOC rule triggers.

Why it fails: While Cortex XSOAR can automate responses, the scenario asks for a configuration within Cortex XDR. Using an external playbook introduces dependency and latency, and is not the native method for assigning alerts from a BIOC rule. The built-in BIOC settings are simpler and direct.

Use the Cortex XDR API to pull raw alert JSON and process it in an external BI tool without any XQL or dashboard involvement.

Why it fails: While the API can retrieve alert data, the scenario asks which Cortex XDR capabilities to use to build the report. An external BI tool is outside Cortex XDR, and the engineer would still need to define aggregation logic. This option does not leverage the platform's built-in aggregation or visualization features.

Use the Reports module to schedule a quarterly PDF that summarizes alert counts grouped by endpoint.

Why it fails: The Reports module produces scheduled or on-demand summaries, but it does not natively support the combined grouping by endpoint and MITRE technique with a top-ten ranking in a single output. Relying on it alone would not deliver the specific MITRE technique breakdown requested, so it is insufficient here.

Use the Incident Response view to manually tag each high-severity alert with the endpoint name and technique before exporting.

Why it fails: Manual tagging in the Incident Response view is labor-intensive, error-prone, and does not scale to a quarter's worth of alerts. It also produces no aggregate ranking or technique frequency analysis, so it cannot deliver the required top-ten and MITRE breakdown.

dataset = xdr_data | filter causality_id = "<ID>" or parent_causality_id = "<ID>" | fields actor_process_image_name, causality_id, parent_causality_id

Why it fails: This query includes events where the causality_id matches the given ID or where the parent_causality_id matches it. This captures the alerting process and its immediate children, but not its ancestors. The initial infection vector is likely a parent or grandparent, so this query misses the chain leading up to the alert.

dataset = xdr_data | filter causality_id = "<ID>" | join (dataset = xdr_data | filter causality_id = parent_causality_id) as chain | fields chain.actor_process_image_name

Why it fails: This query attempts a join but is incorrectly structured; the join condition is invalid because parent_causality_id is not a field in the outer query. XQL joins require matching fields between datasets. To traverse the chain, a recursive approach or the built-in causality chain view is needed, not a simple join.

dataset = xdr_data | filter causality_id = "<ID>" | fields actor_process_image_name, causality_id, parent_causality_id

Why it fails: This query filters events by the given causality_id, but it only returns events where the causality_id matches exactly. It does not traverse the parent chain to retrieve ancestors. To get the full chain, the query must follow parent_causality_id links recursively or use a specific XQL function for causality traversal.

dataset = xdr_data | filter agent_hostname = "FIN-WS-042" and event_type = NETWORK | filter action_local_ip not in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") and action_remote_ip not in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") | fields action_remote_ip, action_remote_port

Why it fails: This query filters both local and remote IPs to be outside private ranges. However, the local IP of an endpoint in a corporate network is typically private, so this condition would exclude all legitimate outbound connections from the endpoint. The requirement is to find external remote IPs, not to require the local IP to be public.

dataset = xdr_data | filter agent_hostname = "FIN-WS-042" and event_type = NETWORK | filter action_local_ip not in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") | fields action_remote_ip, action_remote_port

Why it fails: This query filters on the local IP address not being in private ranges, but the goal is to identify external remote IPs. Filtering local IPs would exclude internal-to-external traffic where the local IP is private, which is the opposite of what is needed. The correct approach must filter the remote IP against the allowlist or private ranges.

dataset = xdr_data | filter agent_hostname = "FIN-WS-042" and event_type = NETWORK | filter action_remote_ip in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") | fields action_remote_ip, action_remote_port

Why it fails: This query uses `in` instead of `not in`, so it returns only connections to private IP ranges. That is the inverse of the requirement, which is to find external connections. Private IPs are typically internal and would be part of the allowlist, not the suspicious external traffic the engineer seeks.

Change the agent operating mode to Bypass.

Why it fails: Bypass disables enforcement entirely, so the BIOC rule stops generating alerts rather than being tuned, losing detection coverage during deployments. It tempts because Bypass is used for troubleshooting agent conflicts or performance issues, not for refining noisy detection logic.

Disable the entire Analytics engine on all endpoints.

Why it fails: Disabling the Analytics engine removes all detection across every rule, far beyond the noisy BIOC. The proportionate step is tuning that rule — adding exclusions or conditions — while Analytics stays enabled; engine-wide disablement is reserved for catastrophic false-positive storms, not routine deployment noise.

Delete the BIOC rule and rely solely on default cloud-delivered IOCs.

Why it fails: Deleting the rule discards its detection logic entirely, leaving only vendor IOCs that cannot cover organisation-specific behaviour. Detection engineering tunes or scopes the BIOC instead; deletion is warranted only when the technique is permanently irrelevant, not during a temporary deployment-related false-positive spike.

Agent Settings -> Profiles -> Analytics

Why it fails: Agent Settings → Profiles → Analytics governs endpoint behavioural policy, not dashboard visualisation. It configures analytics exclusions and profile-level detection behaviour applied to agents, so it cannot render a top-10 alert-volume widget. It would be the right place to tune which analytics run on an endpoint group, not to build reporting views.

Threat Intelligence -> Feed Management

Why it fails: Feed Management configures external threat intelligence sources and indicator ingestion, not dashboard widgets. It is tempting because alert data draws on threat intel, but widget creation happens in the Dashboards section, where the analyst selects the alert dataset, applies a seven-day filter and groups by endpoint.

Incident Response -> Playbooks

Why it fails: Playbooks define automated response workflows triggered by incidents, not dashboard visualisation queries. It is tempting because both sit under Incident Response, yet widget creation requires the Dashboards or Reports area, where the analyst defines the dataset, filters and top-10 aggregation over the seven-day window.

Incident Export via Syslog

Why it fails: Syslog export forwards incident events to an external syslog receiver in real time; it neither generates PDFs nor emails them. It tempts because it automates incident data delivery, but the destination and format are wrong for a weekly emailed PDF report to the security operations team.

Data Export Service

Why it fails: Data Export Service streams raw endpoint and incident data to external destinations such as syslog or S3, not formatted PDF reports. It tempts because it exports incident data on a schedule, but it delivers machine-readable records, whereas the requirement is an emailed PDF report.

BIOC Alert Notifications

Why it fails: BIOC Alert Notifications push notifications when BIOC rules trigger; they produce no scheduled PDF report of critical endpoint incidents. It tempts because BIOC alerts are incident-related, but the requirement is a recurring emailed report, which is a reporting feature rather than alert notification delivery.

Agent Malware Prevention profile exception

Why it fails: A Malware Prevention profile exception whitelists files or processes from antivirus scanning; it cannot aggregate sequential connection failures over a rolling window. The engineer needs a correlation or threshold-based BIOC rule type that counts events per source IP within 60 seconds. Exceptions are tempting when tuning false positives, but they suppress detection rather than define temporal logic.

Local firewall rule configuration

Why it fails: Local firewall rules evaluate individual connection events against static match conditions; they cannot correlate multiple sequential failures from one source across a rolling 60-second window. It is tempting because firewall logs feed the detection, but it would be correct for blocking or alerting on a single matching connection.

Static IOC file hash block rule

Why it fails: Static IOC file hash rules match known malicious file hashes, not sequences of network connection failures over time. It is tempting because it is a detection rule type, but it would be correct for flagging files whose hashes appear on a threat-intelligence blocklist, not for behavioural port-scan correlation.

The Linux agents must be rebooted into Diagnostic mode for BIOC evaluation.

Why it fails: Diagnostic mode is a Windows-only Cortex XDR troubleshooting state; Linux agents evaluate BIOCs in normal operation. The genuine cause is platform-specific BIOC syntax, since Linux uses different process, path and command fields than Windows, so identical commands require separate rule definitions.

Linux endpoints do not support custom BIOC rules in Cortex XDR.

Why it fails: Cortex XDR supports custom BIOC rules on Linux agents, so platform-wide non-support is false. The real cause is usually BIOC syntax or event fields that differ between Windows and Linux telemetry. It is tempting because Windows and Linux do collect different event types, but that is a field-mapping issue, not absent support.

Custom BIOCs require Cortex XSOAR to process Linux telemetry.

Why it fails: BIOC rules are evaluated by the agent against local telemetry; XSOAR is a separate SOAR platform for orchestration and playbooks, not a telemetry pipeline for Linux endpoints. It is tempting because XSOAR integrates with Cortex XDR, and would be correct if the scenario involved automated response workflows rather than rule matching.

Host Insights Query Builder

Why it fails: Host Insights Query Builder searches endpoint telemetry retrospectively using XQL; it does not author or test BIOC rules. BIOC creation requires the BIOC Editor. Query Builder would be correct for hunting historical activity across hosts after a detection hypothesis is formed.

Cortex XSOAR Playbook Designer

Why it fails: XSOAR Playbook Designer builds automated response workflows, not BIOC detection logic. Writing and testing a BIOC requires the BIOC Editor, which validates rule syntax against Cortex XDR's causality data. Playbooks would be correct for orchestrating remediation after a BIOC alert fires.

IOC Management under Malware Protection

Why it fails: IOC Management stores static indicators such as hashes, IPs and domains for matching, not behavioural logic. A BIOC needs the BIOC Editor to express process and causality conditions. IOC Management would be correct for blocking known-bad file hashes or network artefacts.

Host Insights -> System Explorer

Why it fails: Host Insights and System Explorer display endpoint inventory, running processes and artefacts, not the cross-artefact causality chain linking a phishing email to credential dumping. The option tempts because it is host-level forensic data, but Attack Story requires the Causality View, which reconstructs the incident's sequence of related events.

Reporting -> Scheduled Reports -> Attack Chain

Why it fails: Scheduled Reports generate periodic summaries and dashboards, not interactive per-incident causality chains. The option tempts because it mentions an attack chain, but reporting aggregates historical metrics, whereas the Attack Story is examined in the incident's Causality View, which maps related events into a visual sequence.

Settings -> Configurations -> Causality

Why it fails: Settings and Configurations hold console administration options; no Causality entry exists there. The option tempts because the word Causality matches the Attack Story concept, but configuration screens manage policies and integrations, whereas the causality chain is viewed through the incident's Causality View, not a settings page.