Just migrated a few services onto Absolute Secure Access's 'zero trust' gateway. Now our central dashboard is a sea of blue 'low risk' alerts. We're talking hundreds per day: `User accessed application from new city`, `Device posture check passed (but with a minor TLS version flag)`. It's drowning out actual medium/high severity events.
I've poked around the policy engine, but the granularity seems... lacking. The predefined `Low Risk Alert` rule appears to be a monolithic catch-all. I need to filter out the noise, specifically:
* Geolocation alerts for known, trusted users on managed devices.
* Redundant `posture check passed` alerts that carry negligible risk (like the aforementioned TLS ciphers).
Has anyone reverse-engineered a way to do this without just turning off the entire `Low Risk` category? I'm looking at the API and the config syntax seems to allow for more nuance than the UI presents. Something like this hypothetical filter?
```json
{
"alert_rule": "Low_Risk_Access",
"conditions": {
"suppress_if": [
"user.trust_level == 'high'",
"AND device.managed == true",
"AND alert.subcategory NOT IN ['tls_version', 'geo_city_change']"
]
}
}
```
Or is the product philosophy genuinely "you must sift through all low-severity events to prove you're watching"? If so, that's an interesting audit choice—just not a practical one for a team of three.
- Nina
- Nina
You're on the right track with the API config syntax. The UI is indeed a simplified layer. I've tackled this by moving entirely to a declarative policy-as-code setup using their Terraform provider, which exposes the condition logic the UI hides.
Your hypothetical filter is close. The key is that suppression happens at the policy rule level, not inside the global alert rule. You need to create separate `access_policy` rules for your trusted cohort that simply don't generate the `Low_Risk_Access` signal in the first place. For example, a rule with higher precedence that matches `user_group in ["trusted_admins"] AND device.managed == true` would have its action set to `allow` without emitting the low-risk alert. The monolithic alert rule only fires for sessions that don't match these more specific, silent policies.
Regarding the TLS ciphers, that's a separate feed from the posture assessment service. You can tune its sensitivity through the `device_posture` integration settings, downgrading specific technical checks from `alert` to `log_only`. That stops the alerts at the source.