Hey everyone, I've been diving deep into our Sophos XGS setup lately, trying to adopt a more product-led, data-informed approach to our internal security policies. It's been a fascinating experiment! I'm usually tracking user adoption and feature flags in SaaS products, so applying that same analytical mindset to firewall logs is a fun crossover.
Here’s my current puzzle: I can see that blocks are happening (which is great!), but I'm hitting a wall when I try to get to the *who* behind the *what*. For example, if a policy blocks access to a high-risk category or a specific site, the logs show the IP and the action, but often lack the definitive username of the person who triggered it. This makes cohort analysis—like understanding if blocks are coming from a specific department, new hires, or a particular device type—really tricky.
I've been poking around in the Web Admin console and Log Viewer. I see the standard log columns:
* Date/Time
* Source/Destination IP & Port
* Policy Name
* Action (Block/Allow)
* Application/Website Category
But the crucial piece—the authenticated user identity—seems inconsistent or missing. I know user identification relies on integration (like with Active Directory via User Agent or Captive Portal). My setup is using AD integration, and users authenticate for web filtering.
So, my detailed questions for this savvy community:
* What's the **exact log field or report** I should be looking at to reliably see the username tied to a block event? Is it buried in an advanced column I need to enable?
* Are there specific **pre-built reports** in the Reporting section focused on user activity, or do I need to build a custom one? If custom, what key data sources and filters would you start with?
* Does the detail level depend heavily on the **specific blocking rule** (e.g., web filter vs. application filter vs. IPS)? I'm curious if the data source changes.
* Any **gotchas** you've experienced? For instance, does it fail to capture the user for traffic from certain client types (thick clients vs. mobile) or when the identification agent isn't running?
I'm essentially trying to build a "user adoption funnel" for security policies—who's interacting with blocked resources, how often, and why. This would help us tailor training, refine policies, and calculate the actual ROI of our rules beyond just a block count.
Really appreciate any workflow tips, log config snippets, or reporting strategies you've tested. I'm ready to experiment! 🔥
Try everything, keep what works.
Right? That user-ID gap in the logs is the classic firewall reporting headache. You're on the right track looking at integration.
You mentioned the logs show the action and policy, but not the *who*. That almost always means your user identification source isn't fully wired up or the policy isn't set to require authentication. If you're using something like Active Directory or Azure AD, you need to check the firewall's agent or connector status, and make sure the firewall rule referencing that user/group is actually set to "authenticated users".
I've seen cases where the integration is working for *some* traffic (like explicit proxy) but not for other flows. It's a pain to chase down, but when it works, it's magic for those cohort reports you want.
APIs > promises
Spot on about the integration being key. The "authenticated users" rule setting is a common culprit. A pattern I've seen trip teams up is when they have split traffic - like user909 mentioned. The explicit proxy might be logging user IDs beautifully because it forces auth, but then transparent policies for the same users show nothing but an IP.
A good first check is to grep your raw logs for a known blocked request. If you see a user field but it's empty, that's the authentication source failing. If the field isn't even there, the policy likely doesn't require it. Start with one simple block rule for a test user group and build from there.
Sleep is for the weak