Troubleshooting Scenario Questions

Corporate vehicle fleet GPS tracking logs

Why it fails: Vehicle GPS logs record fleet movements, not workstation activity, so they cannot show local logons, process execution or file access. They are tempting because GPS telemetry is genuine evidence in physical-security or insurance investigations, where proving a vehicle's location at a given time is the actual question.

Office cafeteria refrigerator temperature charts

Why it fails: Refrigerator temperature charts record appliance conditions, containing no authentication, process, or session data tied to the workstation, so they cannot establish local access. It is tempting as an available physical record within the office, but such logs are relevant only to facilities or food-safety investigations, not host compromise.

Office janitorial cleaning supply invoices

Why it fails: Cleaning supply invoices document procurement and vendor billing, holding no logon, session, or file-access artefacts from the workstation, so they cannot show who accessed it locally. It is tempting as a physical record placing staff in the building, but invoices are relevant to facilities or finance audits, not host forensics.

Modifying the local BIOS boot order on every user workstation

Why it fails: Boot order firmware settings have no bearing on directory telemetry; ITDR reads authentication and directory-change events from domain controllers. BIOS changes are relevant when reimaging or booting alternate media, not when configuring log forwarding or audit policies. This step consumes change windows while collecting nothing.

Installing the full Cortex XDR Agent kernel driver directly on all DNS root servers

Why it fails: ITDR telemetry comes from directory-service event logs and authentication traffic, not from kernel-level endpoint sensors on DNS infrastructure. Cortex XDR agents belong on workstations and servers generating process and network events. Installing a kernel driver on DNS root servers adds no AD telemetry and risks destabilising critical name resolution.

Disabling all firewall rules between endpoints and the Active Directory SYSVOL share

Why it fails: ITDR collection depends on audit policy, directory-service logging and service-account permissions, not on SMB access to SYSVOL. Disabling firewall rules broadly weakens segmentation without enabling any telemetry channel. SYSVOL share access matters only for Group Policy processing, so this step addresses an unrelated requirement.

Initiate a Live Terminal session

Why it fails: A Live Terminal session provides remote shell access to the endpoint for investigation and remediation, but it does not isolate the endpoint from the network. The endpoint remains connected, allowing potential lateral movement or data exfiltration. While useful for remediation, it does not fulfill the requirement to isolate the endpoint.

Terminate the malicious process

Why it fails: Terminating the malicious process stops the specific running instance of the ransomware, but it does not prevent other malicious processes or network communication. The endpoint remains connected to the network, and the attacker could restart the process or use other tools. Isolation is required to fully contain the threat.

Block the malicious hash

Why it fails: Blocking the malicious hash prevents the specific file from executing on endpoints, but it does not isolate the already-infected endpoint. The ransomware may already be running and could continue to encrypt files or spread laterally. Blocking a hash is a preventive measure, not a containment action for an active infection.

The BIOS firmware boot order configuration screen

Why it fails: BIOS boot order governs which device firmware hands control to at startup; it holds no records of MSI installer failures or agent service errors. It is examined when a machine boots from the wrong disk, not when diagnosing Cortex XDR installation faults.

The local router routing table via the arp -a command

Why it fails: The ARP cache and routing table reveal nothing about why the Cortex XDR installer failed; they show layer-2 and layer-3 neighbour mappings. The arp command is used to diagnose connectivity or duplicate-IP issues, so it would be relevant when the endpoint cannot reach the management server, not when installation itself aborts.

user_identity_mapping

Why it fails: user_identity_mapping maps identities to users, containing no network connection telemetry. It is tempting because it is a real Cortex XDR table, and it would be the correct choice when correlating usernames with identity data during an investigation.

cloud_storage_bucket_policy

Why it fails: cloud_storage_bucket_policy holds cloud storage bucket policy configuration events, not endpoint network connections. It is tempting because it is a genuine Cortex XDR dataset, and it would be the correct table when investigating misconfigured or exposed cloud storage buckets rather than lateral movement.

agent_upgrade_history

Why it fails: agent_upgrade_history records endpoint agent version upgrades, not network connections. It is tempting because it is a legitimate Cortex XDR dataset, and it would be the correct table when troubleshooting or auditing agent version deployment across endpoints.

That featured fields are enabled for the custom schema

Why it fails: Featured fields must be populated for stitching to match events; without them the rule never correlates. Enabling featured fields is genuinely required when defining a custom schema's searchable columns, so it is tempting, but the failure here is that no incidents form at all, which points to the stitching query or connector rather than field enablement.

That the incident score is locked at maximum

Why it fails: Incident scores are calculated from correlated alerts; locking a score at maximum does not create incidents and no such setting governs stitching. Score locking is used to prevent automatic severity changes on an existing incident, so it is tempting when tuning triage, but it cannot explain why no incidents form from the custom logs.

That all incoming custom logs are starred by default

Why it fails: Starring logs marks them for analyst attention; it neither triggers correlation nor creates incidents. Starring is genuinely useful for flagging notable events during investigation, which makes it tempting, but the absence of incidents stems from the stitching rule failing to match custom schema fields to endpoint events.