How matching works
A custom detection watches one source table and uses aWHERE predicate to decide which events match. A WHERE predicate is simply the filtering part of a SQL query — the conditions that come after WHERE.
For example, these conditions match successful email-send events on the microsoft_ual_logs table:
SELECT, FROM, or the WHERE keyword. Wirespeed adds the source table, your team’s metadata, and the time range automatically.
Each event that matches the conditions creates one detection. This keeps every detection tied to a real source event, with its original time, integration, and related assets available for investigation.
Ask Wirespeed can also check surrounding activity. For example, a rule can match a successful login only when the same user had many failed logins during the previous two hours. The assistant keeps these lookbacks scoped and time-limited so the rule can run reliably.
Suppress repeated detections
Some rules can match several closely related events. You can suppress these repeats by choosing:- The related asset types to compare, such as users, endpoints, files, IP addresses, or domains
- A suppression window of 15 minutes, 30 minutes, 1 hour, 4 hours, 12 hours, or 1 day
Suppression depends on the selected asset being present on the matched event. For example, user-based suppression works only when the event identifies a user.
Before you confirm
Ask Wirespeed checks the connected table and fields, runs the rule against recent data, and shows:- How many events matched
- The source and filtering conditions
- Query performance
- Any repeat-suppression settings

