XDR Analytics BIOC - These are analytics alerts based (mainly) on single events. They are similar to BIOCs, except they also account for a profile of how common or rare something is. Examples are "Uncommon local scheduled task creation via schtasks.exe", "Microsoft Office Process Spawning a Suspicious One-Liner" and "Uncommon user management via net.exe". They are single event (execution of something) that is rarely seen in the environment. XDR BIOC - These are behavioral IOCs, looking for abnormal behavior but not with specific hashes, IPs or domains. An example is " Binary file being created to disk with a double extension" - this rule is not looking at who created the file or what the file is, it's looking for the fact that a file was created with this attribute. Another example is "PowerShell runs base64-encoded commands", "Windows certificate management tool makes a network connection" and "Script file added to startup-related Registry keys". NGFW - These are alerts generated by Palo Alto Network Next Gen Firewall as traffic is going through it. XDR IOC - These are simple IOC matches, including hashes, IPs, domains, files, etc. XDR Analytics - There alerts are similar to Analytics BIOCs, however they are multi-event. An example can be "Random-Looking Domain Names" - this alert groups multiple DNS queries that seem random and alerts when it sees several of them. Additional examples are "Recurring Rare Domain Access", "Failed Connections" and "DNS Tunneling". XDR Managed Threat Hunting - These are alert generated by our Managed Service. XDR Agent - These are alerts generated by the agent itself on the machines. All other alert type above (expect the FW) are generated using the telemetry XDR collects in the cloud, but this one is done by the agent locally when it sees suspicious behavior in real time. Alerts can be malware related, restrictions, exploits and more.
... View more
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 email@example.com Or
... View more