In Seculyze, the "Alert Rules" column provides insight into how many alert rules actively use a specific log source (on a table level) for analysis in your Microsoft Sentinel setup. In other words, the amount of alert rules mapped to log sources.
How It Works
For each log source table, Seculyze identifies how many alert rule queries are referencing that table. This allows you to see which tables are actively contributing to detections — and which are underutilized.
Example
Consider the following alert rule query:
kusto
SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count() by Account = TargetUserName, bin(TimeGenerated, 5m)
| where FailedAttempts > 5
As it might be seen, this rule depends on the SecurityEvent table. In this case, SecurityEvent would receive a count of 1 in the Alert Rules column.
Hovering the Mapped Alert Rules chip allows you see click any rule from the list top Copy the Alert Rule name to your clipboard.
Key Points
The count reflects both native Microsoft and third-party alert rules
Only enabled log sources are included
Mapping is done on the table level, not broad source categories
This helps determine the actual value of each log source in your detection strategy
If a log source shows a low or zero count, it may be worth evaluating whether it’s truly necessary — or if it can be configured to contribute more to threat detection.