External alerts are the alerts from your security products that are processed by Zscaler MDR. Many security teams receive alerts from dozens of sources. These alerts are often difficult to investigate conclusively because they only describe part of the story of what happened.
Zscaler MDR takes alerts from these sources, correlates them together, and—most importantly—determines if there was any activity on your endpoints that corroborates the activity described by the alert. This process of “alert validation” oftentimes dramatically reduces the number of alerts your team needs to review.
The security products that generate these alerts are represented by alert sources in the Zscaler MDR platform. An alert source is a distinct deployment of a security product in your organization. For example, if you have multiple deployments of an IDS/IPS product for different locations, each will be a unique alert source.
Final Alert States
After Zscaler MDR analyzes an alert, its final state will either be Threat or Not a Threat.
Not a Threat
The majority of alerts labeled Not a Threat will have been evaluated via automation. Zscaler MDR’s Detection Engineers analyze historical security alerts to categorize them. This helps remove informational alerts and alerts that wouldn't help us identify actual threats within your environment.
Note
Alerts with insufficient information for threat confirmation are likely redundant with our existing detector coverage powered by behavioral analytics. We understand these alerts might be important for your internal compliance or business functions. However, for threat detection purposes, Zscaler MDR may categorize them as less critical.
Some example scenarios of Not a Threat alerts:
The alert is entirely informational in nature.
An alert represents a status change in an application or system.
A suspicious process or file was observed but was deemed a False Positive after investigation.
A network connection was reset.
Threat
When alerts are included as part of a published Threat, the corresponding alert on the Alerts page will also receive a final alert state of Threat, and customers can see the link to the published Threat it was included in.
Important
Alerts for blocked malware that are later-stage malware, such as C2 infrastructure, hack tools, or ransomware, are alerts that warrant additional investigation and analysis by Zscaler MDR. In those cases, customers should expect to see a published Threat in their portal. Additionally, if there is behavior leading up to the anti-virus mitigation, Zscaler MDR will treat the activity as malicious and publish a Threat.
Connect New Alert Sources to Zscaler MDR
Get started by adding certain alert sources to your security stack and configuring each to send alerts to Zscaler MDR. An alert source represents the security products generating these alerts and can originate from supported integrations or distinct deployments of a security product. For example, if you have multiple deployments of an IDS/IPS product in different locations or configurations, each deployment would be identified as a unique alert source.
To connect an alert source, visit our list of Supported Integrations and follow the specific setup instructions for each security product.
FAQ
How are alerts ingested from security source platforms?
Alerts are collected from alert sources in a number of ways. The ideal transport is to allow the highest fidelity alerts to be processed by Zscaler MDR. The transports supported by alert sources differ depending on the source and can ingested using one of the following methods:
API Poller: Zscaler MDR pulls new alerts every five minutes from the alert source API using credentials that you provide.
Email: For some supported alert sources, Zscaler MDR ingests alerts only via email. For supported alert sources, Zscaler MDR provides an email address that you can use to configure your alert source so as to send alerts to Zscaler MDR. This email address enables you to send emails to an email ingest destination inbox created in Zscaler MDR’s email domain. Once an email arrives in this inbox, Zscaler MDR parses and correlates the alert details. Ingested and processed alerts appear in the Alert section of Zscaler MDR. For alert sources that support TLS, Zscaler MDR supports encryption in-transit via TLS 1.2. If your alert source supports TLS, you’ll typically see a TLS toggle when adding your alert source to Zscaler MDR.
Syslog: Zscaler MDR provides a URL and port for you to configure your alert source to send alerts to via the syslog network logging protocol. This requires TLS v1.2+.
HTTP: Zscaler MDR provides a URL and port for you to configure your alert source to send alerts to via HTTPS webhooks. This requires TLS v1.2+.
TCP: Zscaler MDR provides a URL and port for you to configure your alert source to send alerts to via TCP with TLS. This requires TLS v1.2+.
Can I suppress alerting for penetration tests?
We understand the need to minimize alert noise during penetration testing. However, our internal policy requires publishing all observed threats to maintain complete visibility. Because it isn’t always possible to reliably distinguish between penetration testing tools and actual adversary activity, we do not exclude specific IP addresses or suppress related indicators. This approach helps prevent security blind spots.
If you would prefer not to receive alerts during a penetration test, we recommend temporarily disabling or uninstalling EDR sensors on the target hosts, or pausing your simulation tools.