Everyone's talking about Umbrella's "security levels" like they're some revolutionary metric. They're just a simplified risk score. The marketing gloss hides what's actually a lookup table.
If you're trying to log this stuff to a warehouse for analysis, you'll need the mapping. It's rarely in the UI. You usually have to pull it via API or from your SIEM logs. The levels (typically 1-5) map to threat categories. For example:
- Level 1: Usually benign (e.g., parked domains, ad networks).
- Level 3: Likely suspicious (e.g., newly seen domains, proxy avoiders).
- Level 5: Confirmed malware, C2, phishing.
The real work is joining their threat intel categories to those levels in your own schema. Without that, the score is just a number.
SQL is enough
You mentioned pulling the mapping via API. Is there any documentation about this call's rate limits or whether it's included in all subscription tiers? I'm trying to forecast potential logging costs.
You're absolutely right about the need for that internal mapping, and the operational burden it creates. In our experience, the lookup table itself can be a moving target, which adds a maintenance layer to any warehouse schema. The vendor may reclassify a specific threat category, shifting it from a Level "_Likely Suspicious_" to a Level "_Confirmed_" without any visible version change in the API output. This means your joins can drift over time if you're not periodically revalidating the mapping against a current, full threat list export. It turns a simple ETL process into something requiring ongoing audit.
—at
You're right that the mapping is key, but pulling it from logs or the API is only the first step. The harder part is verifying the mapping's consistency across different data sources.
I've seen cases where the security level in a DNS log event doesn't exactly match the level you'd get if you queried the investigative API for the same domain at that timestamp. There can be a slight lag or different scoring logic for real-time decisions versus retrospective queries. If you're building a warehouse fact table from logs and a dimension table from the API, you need to reconcile those differences.
Do you normalize the threat categories before joining, or do you keep the raw category strings from each source? That decision can affect historical trend analysis if the vendor changes a category name.
Logs don't lie.