Skip to content

Bring Your Own Threat Intel (BYOTI)🔗

The Bring Your Own Threat Intel Detector enables you to integrate Threat Intel indicator lists and generate alerts when those indicators are found in normalized telemetry. The following indicator types are accepted:

  • IP Address
  • Domain
  • URL
  • Filehash (SHA1, SHA256, MD5)

BYOTI Alert Example

Important

Alerts generated by the BYOTI Detector are considered a type of custom alert and are not triaged by Secureworks. For more information, see the How are custom rules supported in Taegis MDR? answer.

Requirements🔗

At least one of the following Threat Intel integrations are required for these alerts to be generated:

Inputs🔗

Detections are from the following normalized sources:

  • Normalized telemetry from supported integrations

Note

There is a limit of 15,000 active indicators per tenant. When indicators reach the limit, the oldest indicators are deleted to remain under the limit.

Outputs🔗

Alerts pushed to the XDR Alert Database and Alert Triage Dashboard. Alerts are grouped by agent ID, sensor ID, or by the indicator.

"detector_id":"app:detect:byoti",
"detector_name":"Bring Your Own Threat Intelligence"

Configuration Options🔗

This detector is enabled by default when the required data sources or integrations are available in the tenant.

MITRE ATT&CK Category🔗

MITRE mapping is based on the signatures of the Threat Intelligence service feeding the BYOTI feature. Check the alert for the specific mapping.

Detector Testing🔗

This detector does not have a supported testing method, though an Advanced Search will verify if alerts originated with this detector.

Note

If no supported testing method is available, an Advanced Search will show you if any alerts came from this detector if a qualifying event was observed. A search with no results does not indicate the detector is not working. A lack of search results for the detector may only indicate that the specific attack has not been observed in the tenant. However, it could indicate the underlying data is not available. Ensure the required schemas are provided in Data Sources along with the supported device type(s) for that schema.

FROM alert WHERE metadata.creator.detector.detector_id='app:detect:byoti'

FAQs🔗

Is there a strategy for what Threat Intel indicators should be ingested into XDR?🔗

The BYOTI Detector generates alerts when an indicator is found in normalized telemetry. Therefore, to avoid noise and false positives, it is important to only load trusted indicators that have been through some level of validation and that need to be alerted upon.

Good indicator feeds should be based on first-hand observations, be recent and not stale, be high fidelity and not false-positive prone, and have appropriate context to act on any alerts. Recent observations of known command-and-control domains or IPs where attempted connections to these indicators would uncover a compromised host are an example of good indicators to alert on.

Important

Do NOT include SSH, FTP, HTTP, or other external Internet scanners. This activity is expected to be occurring against external-facing infrastructure and alerting upon this activity is extremely noisy.

Why does an indicator shown as malicious by a third party not show up in CTU’s Threat Intelligence?🔗

CTU focuses on being a primary source of malicious indicators based on their own observations and telemetry. CTU validates and curates all of their indicators to ensure XDR finds the balance between identifying threat actor activity and generating noise for customers. CTU does add, process, and validate some trusted third-party indicators to their intelligence feeds, but does not pass wholesale feeds of crowd sourced indicators into their intelligence as these indicators are often lacking context making them hard to validate.