A SOC team member implements an incident starring configuration, but incidents created before this configuration were not starred. What is the cause…

The incident starring configuration in XSIAM operates on a forward-looking basis. The rules you define are applied to newly ingested alerts as they are processed. If an incoming alert matches the criteria of a starring configuration, that alert is starred. Subsequently, any incident that contains one or more starred alerts will also be marked as starred. This process is not retroactive; therefore, alerts and incidents that were created before the configuration was saved and activated are not affected.

A. Manual starring is a separate feature and not the cause of the automatic configuration's behavior. The automatic process does not require any manual follow-up for new incidents.

B. There is no standard 48-hour propagation delay for starring configurations to take effect. The rules are applied to new alerts as soon as the configuration is active.

C. This statement is partially correct in that starring is applied to alerts, but it is incorrect in stating that incidents are not starred. The primary goal is to star the incident, which is achieved by starring its underlying alerts.

1. Palo Alto Networks XSIAM Administrator's Guide:

Section: Star an Incident

Content: "You can configure Starring to automatically star newly ingested alerts that match the criteria you define in an XQL query. When an alert is starred, the incident it belongs to is also starred." This confirms that the logic applies to newly ingested alerts and that the incident's status is derived from the alert, explaining why pre-existing incidents are not affected.