IOC Exclusion for when an IOC was denied by the FW

PA_nts — Tue, 02 Jun 2026 14:53:33 GMT

Hi All,

so when an IOC is added for an IP address for example in XSIAM, and a FW logs containing this IP is ingested to XSIAM, then XSIAM will auto create an alert for this IOC regardless if dropped or allowed by the FW.. it detect this IOC and creates an alert.

has anyone found a solution for IOC not to trigger when the FW action has already dropped this traffic? Exclusion rules does not have a field option for the FW drop action so cannot add an exclusion rule based on the IOC detection method where the FW action was dropped.

any ideas?

thanks in adv

Re: IOC Exclusion for when an IOC was denied by the FW

susekar — Tue, 02 Jun 2026 19:20:14 GMT

Hello @PA_nts ,

Greetings for the day.

In Cortex XSIAM, it is expected behavior for Indicator of Compromise (IOC) rules to trigger alerts regardless of whether the traffic was allowed or dropped by the firewall. This design is intended to provide visibility into blocked attacks that might otherwise go unnoticed.

Currently, the "Action" field from the underlying firewall log (for example: drop, deny, accept) is often not available as a filterable criterion within the standard Alert Exclusion or IOC Rule logic.

To address this and reduce alert noise for traffic that is already being dropped, you can use the following approaches:

1. Alert Exclusions by IOC Value or Rule ID:

While you cannot filter by the firewall action, you can suppress noise from specific, high-volume IOCs that are already being successfully blocked.

Identify the Rule ID: Locate the specific IOC Rule ID or Alert Name causing the noise (for example: IOC (1.2.3.4)).
Create an Alert Exclusion: Navigate to:

Settings → Exceptions Configuration → Alert Exclusions

Create a rule where the Alert Name or Rule ID matches the noisy indicator.

Note: This suppresses the alert entirely for that IOC, regardless of the firewall action.

2. Issue Exclusions:

If you want alerts to remain visible in the Alerts table for auditing purposes but prevent them from generating incidents or triggering playbooks:

Navigate to:

Incident Response → Incident Management → Exclusion Rules

Create an Issue Exclusion rule using the relevant IOC Rule ID or Alert Name.

This prevents alerts from overwhelming incident queues and playbook processing.

3. Firewall-Side Tuning (For Threat Logs):

If IOC matches originate from firewall Threat Logs (where the detection method appears as PAN NGFW😞

Change Severity: Modify the severity of the specific firewall signature to Informational. XSIAM generally generates alerts only for Medium, High, or Critical severity threat logs.
Signature Exceptions: Configure a signature exception directly on the PAN-OS firewall to stop the log from being generated and forwarded to XSIAM.

4. Advanced Solution: Correlation Rules with Lookups:

If you require alerts only when traffic is allowed, you can bypass the built-in IOC engine using a custom correlation approach.

Create a Lookup Dataset: Upload your malicious IP list into a Lookup Dataset.
Disable the IOC Rule: Disable the built-in IOC rule for those specific IPs to prevent automatic alert generation.
Create a Correlation Rule: Build an XQL-based correlation rule that joins firewall traffic logs with the lookup dataset and explicitly filters for allowed traffic.

Example:

dataset = panwngfwtrafficraw
| filter action != "drop"
| join type = inner (
    dataset = yourlookupdatasetname
  ) as lookup (
    lookup.ip = sourceip or lookup.ip = destip
  )

Adjust the action filter according to the values used in your environment’s firewall logs.

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".