Cortex XDR Agent profile: content auto-update delay

[RobertoPastorino]

Hi everyone, I was wondering how the content auto-update delay feature works when a CU borks a system.

Last week we experienced a sudden spike in cpu and ram usage, and the affected machines crawled and stuttered, impacting production. Support told us to wait for a specific content update to be released, which would (as had been appened) correct the problem.

So, in a scenario like this:

Agent profile grp_CriticalServers : cu delay: 3 days.
Agent profile grp_Workstations: cu delay: none

day 0: CU 500-00001 released, applied on grp_Workstations , grp_CriticalServers still on CU 500-00000
day 1: CU 500-00001 works as expected
day 2: CU 500-00002 wreak havoc on grp_Workstations, grp_CriticalServer still on 500-0000

day 3: CU 500-00003 and CU 500-00004 released , grp_Workstations now working normally.

Question: at day 3, which content update will be served to the grp_CriticalServers? The last available 00004 ? 00001 and then after another 3 days, all the critical servers will be affected by the problematic CU 00002?

In the first case, going straight to the last available come with some risks, the latter is not acceptable if there is no way to deprecate a CU. Or there is?

The end goal is to use the vast majority of machines as canary for the critical servers.

How did you manage a situation like that?

Regards

[bbarmanroy]

Hi @RobertoPastorino you can consider using rollout delay for Content Updates to meet your needs. You will need to create a separate Agent Settings Profile and assign them to targetted endpoints.

Refer to Step 12: https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/endpoint-security/customiza...

[RobertoPastorino]

Hi, thank you for your reply, but this has already been considered.

What I don't know is the way the content updates are managed in the scenario depicted.



What happens when a CU is going rogue and start to create problems to the endpoints were is deployed? In a delayed deployment , there is a method to exclude a specific content update from the available ones? This should be the ratio behind the delay , test a CU before deployment in a critical environment. But how can I be certain that a delayed, problematic update, won't be pushed to the agent?





BR

[afurze]

Hi RobertoPastorino,

In a case like this where a CU is identified as causing issues by Palo Alto Networks, the CU gets rolled back and then replaced.  The endpoints that are delayed will never receive the "bad" CU, they will just get the next CU after the delay period ends.  For example:

Hour 0: New CU released, agents with out delay get updated

Hour 24: CU is identified by PANW as causing issues, CU is rolled back

Hour 48: New CU is released, agents without delay get updated

* 72 hours after new CU released, so hour 120 *

Hour 120: New CU is installed to agents with delay

These are just hypothetical numbers, issue discovery, CU rollback and replacement are always dynamic and unique to a specific issue.

[RobertoPastorino]

Fantastic, this is what I hoped to be the case 🙂

So, content updates are not cached locally and are revoked / Replaced by PAN .



Thank you!