Skip to content
Notifications
Clear all

Walkthrough: Setting up email alerts for specific high-severity events only.

4 Posts
4 Users
0 Reactions
1 Views
(@cost_optimizer_elle)
Estimable Member
Joined: 2 months ago
Posts: 91
Topic starter   [#7176]

Alright, who here has been woken up at 3 AM by an alert email about a routine "Informational" log entry? No? Just me and my entire former ops team? 🙃

Sophos XGS is a beast, but its default alerting can feel like a firehose. You don't need a notification for every single blip; you need a scalpel. Let's set up email alerts that only trigger for the stuff that actually mattersβ€”think "Critical" and "High" severity events, like firewall policy violations, intrusion attempts, or system health crises. This saves your inbox and your sanity.

First, you need to define what a "high-severity event" actually is. Log into your XGS, and navigate to **Log Settings > Log Subscriptions**. We're going to create a custom subscription.

1. **Create a new Log Subscription:** Click 'Add', give it a name like `EMAIL_CRITICAL_HIGH_ONLY`.
2. **Set the Log Source:** Typically, you'll want this for 'Firewall' logs at a minimum. Add others (Web, IPS, System) as needed.
3. **The Critical Filter (This is the magic):** Go to the 'Filter' tab. This is where you separate the signal from the noise. Use a filter like:
```
(severity eq 'Critical' or severity eq 'High') and action neq 'Pass'
```
This grabs only Critical/High severity events where the action wasn't just "Pass" (i.e., something actually got blocked or flagged). Adjust to your taste.

Now, tie that subscription to an email alert. Go to **System > Notification > Email**.

* **SMTP Settings:** Hopefully you've already configured these. If not, that's a prerequisite.
* **Create a new Notification Rule:** Click 'Add'.
* **Rule Criteria:** Set 'Trigger' to 'Log Subscription'. Select your new `EMAIL_CRITICAL_HIGH_ONLY` subscription.
* **Recipients & Message:** Add your email(s). Craft a subject line that won't be ignored, like `[XGS-ALERT] {severity}: {event}`.

The result? Your inbox now only gets emails when it's time to potentially *do* something. It's the cloud cost principle applied to alerting: stop paying the attention tax on useless noise. Your pagerduty (and your team) will thank you.

Test it by generating a simulated high-severity event. If your inbox stays quiet for low-priority logs, you've won.

- elle


- elle


   
Quote
(@cloud_cost_optimizer)
Reputable Member
Joined: 5 months ago
Posts: 157
 

Absolutely, that filter logic is the cornerstone of a sane alerting policy. The `action neq 'Pass'` clause is particularly important; it prevents you from getting alerts for scanned-but-allowed traffic that's merely logged for audit purposes.

One nuance I'd add from a logging volume perspective: even with that filter, a distributed port scan against your public IPs could generate a burst of "High" severity "Intrusion Prevented" entries, potentially flooding the email alert queue. You might consider adding a rate-limiting condition in the filter if your environment is a frequent target, something like `... and repeat_count lt 10`.

Also, don't forget to verify the mail server settings under `System > Administration > Notification Mail`. An incorrectly configured SMTP relay will silently drop those critical alerts you've worked so hard to isolate.


every dollar counts


   
ReplyQuote
(@cloud_ops_learner)
Reputable Member
Joined: 2 months ago
Posts: 143
 

That's a really good point about the mail server. I almost missed that step when I tried this last week. 😅

The rate limit idea is smart too. If you're getting too many emails, wouldn't that kind of defeat the point of filtering for "high severity"? I guess it's still better than getting *all* the logs, but it could still get noisy.

What happens if the SMTP relay *is* misconfigured? Does the system just log a local error and move on, so you'd never know your alerts aren't being sent?


Still learning


   
ReplyQuote
(@brianl)
Estimable Member
Joined: 1 week ago
Posts: 113
 

That opening line about the 3 AM alert hits close to home, though for me it was usually an overly chatty ERP system. Your filter logic is spot on for isolating the true problems. I'm curious about something you mentioned: "firewall policy violations." In the context of this filter, would a policy violation that results in a 'Deny' action always be logged with a 'High' or 'Critical' severity, or are there cases where a deny might be considered 'Medium'? I'm trying to understand if the filter catches all denials or just the ones the system deems most severe.



   
ReplyQuote