Cortex XDR Exclusions vs Exceptions

[JimWaZ]

Hello all,

Exclusions versus Exceptions, why is excluding an alert so much easier than creating an exception when it should be the opposite? 

According to Palo Alto, "If you do not want Cortex XDR to display alerts that match certain criteria, you can create an alert exclusion policy. After you create an exclusion policy, Cortex XDR hides any future alerts that match the criteria, and excludes the alerts from incidents and search query results." In regards to alert exceptions, PA states "In some cases, you may need to override the applied security policy to change whether Traps allows a process or file to run on an endpoint." In practically all cases I am going to need to override the security policy that is blocking a homegrown PE that allows a department the ability to control their TV with their coffee cup. Do I want to just ignore (exclude) the action, and allow the Cortex agent to continue blocking the coffee cup from changing the channel? NO! The department is going to be irate with me because I can't even see the blocking action.

Within Cortex XDR it is easy to create an exclusion, you can right-click, exclude, you're done.  For an exception, you need to pull your exception attributes from the alert, open the exception page, and input attributes where they are needed.  Why can't I right-click a hash, process, description, etc., and add as an exception?  Take it a step further, would you like to add this hash or whatever as a global exception or apply to a specific policy? 

As a security analyst, I'm not going to suppress an alert but still allow it to continue blocking the file, process, etc.  I need to see all that is happening and suppressing an alert but allow the blocking action to happen is probably the last thing I'm going to do. This exclusion action can be buried deep in the Cortex realm of dark actions that never get used.

[Tobi]

Why no answer yet?

[ocohen]

Hi @JimWaZ 

My name is Or and i'm from the XDR PM group.

Allow me to explain.

The right click --> exclusion option is meant to quickly hide FPs but it does not create any policy or changes anything. It will not suppress future alerts of the same type, nor will it cause them to not fire. It's just for that one alert.

The reason the process is a different for an exception is because we want to allow the granularity of choosing who gets this exception. You can do it by profile + policy, hence only some machines get it (so according to your example,  in some sections of the company a coffee cup will be able to change channels and in other it won't) or apply it to all endpoint as a global exception. There are many cases in which you need more granular policies like this.

Another, more specific option, is to add a hash to the allow list - which can be used for cases where you know the hash and you don't expect it to change. It probably won't be effective in cases where dev teams build/test a lot of code.

I hope it helps, but if you want i'd be happy to have session with you to dive deeper into this and listen to any feedback you may have as we're always happy to get any feedback and improve our workflows.

Please email me if you are interested at ocohen@paloaltonetworks.com

Or

[RSteffens]

Thank you! @ocohen You mentioned: "You can do it by profile + policy, hence only some machines get it:". 

Can you or someone post documentation about how to set an exception like this, with a profile + policy? 

I would like more details on how to set an exception for only certain computers in a fleet, like this. 

[bbarmanroy]

@RSteffens you can create a Security Profile as per your requirements, and then attach it to a policy where you choose the list of endpoints you wish to apply on, i.e., dynamic or static groups, list of endpoints, operating systems, endpoints based on domain groups, or other criteria as you may deem fit. The process to create a policy is detailed here, and you'd be looking at Step 6.

[Jeffrey7034]

---

@rapidfs wrote:

Hello all,

Exclusions versus Exceptions, why is excluding an alert so much easier than creating an exception when it should be the opposite? 

According to Palo Alto, "If you do not want Cortex XDR to display alerts that match certain criteria, you can create an alert exclusion policy. After you create an exclusion policy, Cortex XDR hides any future alerts that match the criteria, and excludes the alerts from incidents and search query results." In regards to alert exceptions, PA states "In some cases, you may need to override the applied security policy to change whether Traps allows a process or file to run on an endpoint." In practically all cases I am going to need to override the security policy that is blocking a homegrown PE that allows a department the ability to control their TV with their coffee cup. Do I want to just ignore (exclude) the action, and allow the Cortex agent to continue blocking the coffee cup from changing the channel? NO! The department is going to be irate with me because I can't even see the blocking action.

Within Cortex XDR it is easy to create an exclusion, you can right-click, exclude, you're done.  For an exception, you need to pull your exception attributes from the alert, open the exception page, and input attributes where they are needed.  Why can't I right-click a hash, process, description, etc., and add as an exception?  Take it a step further, would you like to add this hash or whatever as a global exception or apply to a specific policy? 

As a security analyst, I'm not going to suppress an alert but still allow it to continue blocking the file, process, etc.  I need to see all that is happening and suppressing an alert but allow the blocking action to happen is probably the last thing I'm going to do. This exclusion action can be buried deep in the Cortex realm of dark actions that never get used.

---

The reason the process is a different for an exception is because we want to allow the granularity of choosing who gets this exception. You can do it by profile + policy, hence only some machines get it (so according to your example,  in some sections of the company a coffee cup will be able to change channels and in other it won't) or apply it to all endpoint as a global exception.