Select Two (Multi-Select) Questions

Installed printer driver versions

Why it fails: Printer driver versions are not an endpoint attribute Cortex XDR collects or filters on; grouping uses fields such as operating system, hostname, domain, endpoint tags and agent version. It is tempting because driver inventory appears in asset-management tooling, where it would legitimately drive patch reporting.

Local user desktop wallpaper resolution settings

Why it fails: Desktop wallpaper resolution is not an endpoint attribute Cortex XDR collects or filters on; grouping uses fields such as operating system, hostname, domain, endpoint tags and agent version. It is tempting because display settings are visible in some endpoint-management consoles, where they would legitimately drive configuration profiles.

Physical serial number of the endpoint monitor

Why it fails: Monitor serial numbers are not an endpoint attribute Cortex XDR collects or filters on; grouping uses fields such as operating system, hostname, domain, endpoint tags and agent version. It is tempting because hardware serials appear in asset inventories, where they would legitimately drive warranty or replacement tracking.

Reinstall the Cortex XDR Agent on all high-priority servers.

Why it fails: Reinstalling agents changes nothing about how incidents are scored; severity derives from BIOC rules, alert sources, and scoring configuration. It is tempting because agent faults can cause missing or malformed alerts, and reinstallation would be correct when an endpoint reports no telemetry at all.

Modify the Broker VM packet buffer size.

Why it fails: Broker VM packet buffer sizing governs traffic capture and forwarding performance, not the analytics that compute incident scores. It is tempting because Broker VM tuning affects data reaching the console, and it would be correct when resolving dropped packets or collection throughput problems rather than severity misalignment.

Configuring the agent to act as a primary DNS server for the local subnet

Why it fails: The Cortex XDR agent is an endpoint security component and provides no DNS server role; making it authoritative for a subnet would break name resolution. It tempts when consolidating infrastructure roles, but DNS belongs to dedicated servers or managed services.

Ensuring local endpoint users have full domain administrator rights permanently

Why it fails: Permanent domain administrator rights for all users violate least privilege and widen the attack surface the agent is meant to protect. It tempts when agents need elevated permissions to install or update, yet those rights should be granted temporarily to deployment accounts only.

Configure the Broker VM to use a static public IP address for cloud communication.

Why it fails: A static public IP address is not required for the Broker VM to communicate with the Cortex XDR cloud. The Broker VM can use a dynamic IP address as long as it can establish outbound connections. A static IP might be useful for firewall rules on the cloud side, but it is not a requirement.

Configure inbound access from the internet to the Broker VM on TCP 443 for log ingestion.

Why it fails: Inbound access from the internet is not required for log ingestion. The Broker VM initiates outbound connections to the Cortex XDR cloud and can receive logs from internal sources. Allowing inbound internet access would introduce unnecessary security risks and is not a recommended practice.

Enable inbound access from the Cortex XDR cloud to the Broker VM on TCP 443 for management.

Why it fails: The Broker VM does not require inbound access from the Cortex XDR cloud. All management and communication are initiated by the Broker VM outbound to the cloud. Inbound access would be a security risk and is not part of the standard architecture.

Windows Event Viewer Security log on unmanaged workstations

Why it fails: Unmanaged workstations generate no Cortex XDR telemetry, so their Security log cannot explain an API query or automation failure. It is tempting because Event Viewer is the standard place to diagnose Windows authentication and service errors, and it would be the right source when troubleshooting endpoint agent issues on managed hosts.

Local BIOS firmware event logs

Why it fails: BIOS firmware event logs record hardware and platform-level events on the endpoint, unrelated to API authentication, query syntax or automation execution. They are appropriate for diagnosing firmware or boot issues, not for tracing a failing Cortex XDR API call.

Cortex XDR Agent installation MSI error logs

Why it fails: MSI installation logs record agent deployment failures on endpoints, not API request handling or script execution errors. They are the right source when agents fail to install or upgrade, not when a Cortex XDR API query or automation script returns errors.

The physical memory allocation limit on the Broker VM handling syslog collection.

Why it fails: Broker VM memory allocation governs syslog ingestion capacity, not alert rule definition. It is tempting because Broker VMs appear in Cortex XDR deployment sizing, but a scheduled XQL rule requires a query, a schedule and an alert name/severity, none of which reference Broker VM memory.

The kernel bypass configuration parameters for Windows endpoints.

Why it fails: Kernel bypass settings tune endpoint network capture performance, unrelated to scheduled XQL alert configuration. It is tempting because kernel bypass appears in Cortex XDR endpoint agent tuning, but scheduled rule creation requires the XQL query, its run schedule and alert details instead.

Recompile the Linux kernel on the Broker VM appliance to optimize memory paging.

Why it fails: Recompiling the kernel is unsupported on the Broker VM appliance and cannot address memory pressure from log ingestion or forwarding. It is tempting because kernel tuning affects memory paging on general-purpose Linux hosts, but Cortex XDR diagnostics instead review Broker VM logs, service status and resource allocation.

Change the Broker VM disk partition table using fdisk.

Why it fails: Editing the disk partition table with fdisk alters storage layout and risks data loss; it cannot diagnose memory pressure. Partitioning is used when resizing Broker VM disk allocation during deployment, not for investigating RAM consumption, which requires reviewing broker service logs and memory metrics instead.

Publishing the XDR console URL with embedded credentials so the ticketing tool can scrape the incident table.

Why it fails: Scraping a console URL with embedded credentials is not a supported integration and violates security practice. It is brittle, breaks on UI changes, and exposes privileged credentials. Cortex XDR does not sanction this pattern for external delivery, so it cannot serve as a legitimate automated forwarding method and should never be recommended.

Relying on the built-in email notification for every alert and letting the ticketing platform parse the mailbox.

Why it fails: Email notifications are intended for human recipients, not as a structured machine interface. Parsing mailboxes is fragile, lacks guaranteed delivery semantics, and cannot reliably carry the fields a ticketing system needs. While it might loosely move information, it is not a supported integration capability and does not meet the automation requirement cleanly.

Exporting the local agent database and mounting it on the ticketing server as a shared volume.

Why it fails: Endpoint agent data is not a supported integration surface, and mounting internal storage on another host bypasses access controls. This would expose raw telemetry, violate least privilege, and provide no structured incident records suitable for ticketing. It is neither a documented nor a secure mechanism for delivering alerts to external systems.

Write raw binary data directly to the host hypervisor kernel memory space

Why it fails: Integration scripts run sandboxed in Docker containers with no host kernel access, so writing to hypervisor memory is impossible and would breach platform isolation. Such privileged memory access belongs to kernel drivers or hypervisor tooling, not Cortex XSOAR automations, which interact with incidents through the demisto context and commands.

Execute infinite `while` loops without sleep intervals to maximize CPU usage

Why it fails: Tight infinite loops without sleep starve the integration's worker threads, exhausting CPU and blocking concurrent tasks until the platform kills the run. Sleep intervals or bounded iterations suit polling loops that wait for external events. Unbounded spinning is never a standard practice for reliable automation execution.

Print debug passwords in plain text to public stdout logs

Why it fails: Stdout logs persist in the War Room and are visible to every incident responder, so printing passwords exposes credentials and violates platform security guidance. Secrets belong in the credential store, referenced at runtime. Plain-text debug output suits non-sensitive troubleshooting values only, never authentication material.

TCP port 23 for Telnet remote management

Why it fails: Telnet on TCP 23 is an unencrypted remote-management protocol, not a transport for syslog ingestion or agent communication on the Broker VM. It is tempting because administrators do use Telnet for device CLI access, but Cortex XDR Broker VM ingestion uses syslog over TCP/UDP 514 and agent traffic over TCP 443.

UDP port 69 for Trivial File Transfer Protocol (TFTP) agent staging

Why it fails: TFTP on UDP 69 transfers files only, so it cannot carry syslog messages or agent check-in traffic to the Broker VM. It is tempting because TFTP is commonly used to stage firmware and configuration images, but Broker VM syslog ingestion uses TCP/UDP 514 and agent communication uses TCP 443.

TCP port 3389 for Remote Desktop Protocol (RDP) log streaming

Why it fails: RDP on TCP 3389 provides interactive graphical desktop sessions; it does not stream logs or broker agent communication. It is tempting because administrators routinely use RDP to manage Windows hosts, but Cortex XDR Broker VM syslog ingestion uses TCP/UDP 514 and agent traffic uses TCP 443.

Hard drive manufacturing serial number

Why it fails: Endpoint Management exposes operational status such as agent version, last check-in, operational status and platform details, not hardware manufacturing identifiers. Drive serial numbers belong to asset or inventory tooling. The option confuses device telemetry with physical hardware inventory data.

BIOS cryptographic signature key

Why it fails: BIOS cryptographic signature key is not agent status; Cortex XDR shows operational state such as agent version and last check-in. It is tempting because firmware signing keys relate to endpoint integrity, but that belongs to BIOS verification features, not the Endpoint Management agent status list.

Local administrator password hash

Why it fails: Cortex XDR endpoint status fields cover items such as agent version, operational status and last check-in, not credential material. It is tempting because endpoint modules do surface security-relevant host details, yet password hashes are never exposed; that data belongs to credential-dumping detection, not agent inventory.

Raise the alert severity threshold in the BIOC so that only critical alerts are generated for the on-call team.

Why it fails: Adjusting a BIOC's severity threshold changes which alerts are produced and how they are prioritized, but it does not route notifications to an external collaboration platform or trigger an automated action. It could even reduce coverage by suppressing detections. This setting influences triage priority, not the notification and response pipeline the engineer needs to build.

Increase the endpoint agent heartbeat interval so alerts are reported to the management console more frequently.

Why it fails: The agent heartbeat interval governs how often endpoints check in with the management server for policy and status; it does not control alert delivery to external systems or the execution of automated actions. Shortening it adds management traffic without improving notification reach. This setting is unrelated to both the external notification and automated response requirements.

Enable the built-in malware signature pack and schedule a daily scan on all endpoints in the policy.

Why it fails: Enabling signature packs and scheduling scans improves endpoint detection coverage but does not deliver notifications to an external platform or execute an automated response. These settings affect prevention and detection behavior on endpoints, not alert routing or orchestration. They are valid hardening steps but do not satisfy either of the two stated requirements.

The local BIOS/UEFI secure boot configuration summary file

Why it fails: A BIOS/UEFI secure boot summary file is not produced by Windows or Cortex XDR, and firmware state is checked directly in firmware settings. It tempts when secure boot blocks driver loading, but the actual diagnostic sources are the Cortex XDR installation log and Windows event logs.

The Cisco ISE policy enforcement cache database

Why it fails: Cisco ISE's policy enforcement cache holds identity and authorisation session data for network access, unrelated to a Windows endpoint agent install. It tempts when ISE posture or agent integration is in scope, but Cortex XDR installation failures are diagnosed from the local installation log and the agent installation log directory.

The global Panorama traffic log buffer

Why it fails: Panorama's traffic log buffer records session and threat logs forwarded from managed firewalls; it holds no agent installation diagnostics. It is tempting because Panorama centralises Cortex XDR and firewall logging, so administrators habitually look there, but agent install failures require the local Windows event logs and the XDR agent installation log on the endpoint itself.

Assign identical MAC addresses to all Broker VM instances to simplify switch ARP tables

Why it fails: Duplicate MAC addresses on the same network segment cause severe switching and communication failures.

Configure all agents to connect to a single static Broker VM IP address without failover options

Why it fails: Relying on a single Broker VM creates a single point of failure.

Run Broker VMs exclusively on physical bare-metal hardware without virtualization hypervisors

Why it fails: Broker VMs are delivered as virtual appliances (OVA/QCOW2) designed to run on hypervisors like VMware ESXi or KVM.

Configure the agent to use a static IP address for communication with the Cortex XDR cloud.

Why it fails: Agents do not require a static IP address; they use the endpoint's existing network configuration to reach the Cortex XDR cloud or Broker VM. Requiring static IPs would complicate deployment and is unnecessary. The agent uses DNS and standard networking to establish connections, so this is not an essential consideration for mass deployment.

Disable all other security software on the endpoints before installation.

Why it fails: While conflicts can occur, it is not a requirement to disable all other security software. Cortex XDR is designed to coexist with many security products, though some may require exclusions. Disabling other security software may leave endpoints vulnerable and is not a standard practice. The focus should be on proper configuration and testing rather than blanket disabling.

Pre-install the Cortex XDR content update package on each endpoint to reduce initial cloud traffic.

Why it fails: Content updates are typically downloaded from the Cortex XDR cloud or a Broker VM after installation. Pre-installing content is not a standard practice and may not be supported. The agent automatically retrieves the latest content, so this step is unnecessary and could lead to version mismatches. It is not essential for a successful mass deployment.

Restart the Cortex XDR management console to force rule recompilation

Why it fails: Restarting the management console is not a supported troubleshooting step for BIOC rule evaluation and could disrupt operations. BIOC rules are compiled and distributed through normal policy updates, not by console restarts. This action would not address syntax or policy assignment problems.

Change the rule's severity to Critical to ensure it generates an incident

Why it fails: Severity affects how an alert is prioritized, not whether the rule matches. If the underlying condition never evaluates to true, changing severity will not produce an alert. This action misinterprets the role of severity and does not address the root cause of the non-triggering rule.

Disable all other BIOC rules to isolate the non-triggering rule

Why it fails: Disabling other BIOC rules does not help diagnose why a specific rule is not matching. It reduces detection coverage and could create security gaps. The issue is likely within the rule's logic or its deployment, not interference from other rules, so this action is unnecessary and risky.

Playbook timeout set to 300 seconds

Why it fails: A playbook timeout controls how long a running playbook may execute before being terminated; it does not filter which alerts trigger the rule. Adjusting the timeout has no effect on severity or category conditions. While timeouts are useful for long-running tasks, they are not part of enforcing the alert selection criteria described.

Endpoint group scoped to the 'Malware' group

Why it fails: Endpoint groups organize endpoints for policy assignment and do not represent alert categories. Scoping the rule to an endpoint group named 'Malware' would not filter by alert category and could unintentionally include or exclude endpoints. The category condition belongs in the automation rule's alert filters, not in endpoint group membership.

Exclusion list containing all Medium and Low severity alerts

Why it fails: Exclusion lists are used to prevent specific indicators or entities from triggering detections or actions, not to filter automation rule triggers by severity. Adding Medium and Low alerts to an exclusion list would affect detection behavior rather than automation scoping. The severity filter in the rule itself is the correct mechanism to limit triggering.

Check that the Broker VM has direct SSH access to the endpoint.

Why it fails: Broker VM SSH access to the endpoint is not part of agent-to-cloud communication; the agent initiates outbound TLS to the console, and the Broker VM handles on-premises log and file forwarding. It is tempting because the Broker VM is a real Cortex XDR component, but it is not an SSH proxy for endpoint traffic.

Verify that UDP port 514 is listening locally on the endpoint.

Why it fails: UDP 514 is the syslog port, used for forwarding logs to a collector; the agent's cloud communication uses TCP 443 outbound, so a local syslog listener is irrelevant to console connectivity. It is tempting because log forwarding is a genuine Cortex XDR integration, but that is a separate configuration from agent registration.

Verify that inbound TCP port 22 is open on the endpoint for remote management.

Why it fails: Inbound TCP 22 is SSH for remote administration; the Cortex XDR Agent never requires inbound management connections, since it initiates outbound TCP 443 to the console. It is tempting because port 22 is a common firewall check, but opening it addresses administrator access, not agent telemetry.

Physical office desk location number

Why it fails: Endpoint grouping criteria in Cortex XDR draw on endpoint attributes such as hostname, IP, OS, or tags, not desk numbers, which the platform does not collect. It is tempting because physical location feels like a natural grouping axis, and it would be correct if grouping were performed through a separate asset-management or CMDB integration.

BIOS manufacturer serial number color

Why it fails: BIOS manufacturer serial number is not an endpoint attribute Cortex XDR collects or exposes for dynamic grouping; grouping uses platform, OS version, domain, IP range, tags and similar fields. It is tempting because hardware identifiers feel like stable grouping keys, but they belong to asset inventory, not endpoint policy targeting.

Local user account password expiration date

Why it fails: Agent profiles and dynamic endpoint groups are built from endpoint attributes such as operating system, domain, installed software and IP range. Password expiry is an identity attribute held in Microsoft Entra ID, not collected as an endpoint property, so it cannot drive grouping.

Compiled C++ source code (.cpp)

Why it fails: Cortex XDR ingests IOCs as CSV, STIX/JSON or via API/TAXII, not compiled source code, which is never parsed as indicator data. Source code is tempting because custom parsing logic could theoretically be written around it, but that belongs in an external script feeding the API, not the import itself.

Windows Registry Hive backup (.hiv)

Why it fails: Registry hive backups are binary Windows configuration stores, not a supported indicator format; Cortex XDR accepts structured IOC files such as CSV, STIX and TXT, or ingestion via API. It is tempting because registry artefacts are legitimate forensic evidence, and hive files would be the correct choice when analysing persistence mechanisms rather than importing indicators.