We're preparing for our quarterly SOC 2 audit and I need to provide evidence of exploit prevention. Our environment uses Sophos Intercept X (cloud-managed), and I require a granular, time-bound report of all blocked exploit attempts, not just a dashboard summary.
The default reporting in the Central console is too high-level for an auditor. They will want to see:
* Specific exploit names or CVE identifiers that were blocked.
* Source and destination machines (hostnames/IPs).
* Exact timestamps of each event.
* The action taken (e.g., "blocked," "mitigated").
I've looked through the "Reports" section and the "Threat Analysis Center" log. The data seems to be there, but I cannot find a way to export it in a clean, consolidated format suitable for an audit worksheet.
What is the operational method to generate this? Specifically:
* Is there a built-in report template I'm missing, or is a custom SQL query against the dataset required?
* If using the API, which endpoints and filters yield this specific dataset?
* Are there any known data retention caveats that would prevent pulling a full 90 days?
I need a procedural answer, not a marketing feature list. Our auditor will reject screenshots of a dashboard as insufficient evidence.
Where is your SOC 2?
You've hit the exact pain point with Central. The built-in reports are audit-unfriendly. The operational method is to use the Audit Log Export, not the Threat Analysis Center.
Go to Global Settings > Audit Logs. Set your date range. Use the filter "Event type: Security threat" and "Threat type: Exploit" before exporting to CSV. This will give you the granular list with timestamps, hostnames, and the specific exploit technique names.
One major caveat: the CSV won't include CVE identifiers by default, only Sophos' own exploit classification names like "Heap Spray Detection." You'll need to cross-reference those names with Sophos' own published CVE lists for the auditor, which is an extra manual step. The API endpoint would be `/audit/v1/events`, but the log export is the path of least resistance for a one-time report.
buyer beware, but buy smart
That "path of least resistance" is a great euphemism for a huge manual lift right before an audit. The cross-reference step you mentioned is the real kicker.
Sophos publishes those mapping lists, but they're often PDFs spread across multiple KB articles from different product versions. Good luck mapping "Heap Spray Detection" to a specific CVE for Q3 in under an hour.
Makes you wonder why a premium endpoint suite can't just spit out an audit-ready column. Almost like detailed reporting is an upsell.
Trust but verify.
Oh, you've nailed the biggest hidden cost right there - the manual cross-reference. I had to do exactly that last quarter and it was a mess.
It feels less like an upsell and more like a product team that's never actually had to *use* their own data for compliance. The mapping lists are often outdated by the time you find them.
I've started logging the time it takes just to prep the data, and it's usually 2-3 hours for a quarter. That's a real cost they never talk about. Makes you appreciate tools that just have a "Download for Auditor" button, even if they're less fancy.
The 2-3 hour prep time you've quantified is critical. It exposes the hidden operational tax of what seems like a simple reporting gap. That's measurable technical debt, not just a nuisance.
From an architectural perspective, this gap exists because the detection engine's internal taxonomy is decoupled from the public CVE registry. Mapping them requires a separate, often stale, lookup table. A product team that eats its own dogfood would have been forced to automate this join years ago.
I've seen this pattern in other security tools. The ones designed by teams who also handle compliance build the mapping directly into the data export pipeline. The result isn't fancier; it's just joined correctly at the source.
That architectural explanation makes perfect sense, it's like two separate teams building things. They don't need new features, they just need to connect the data they already have.
Do you know any tools that *do* get this right? I'm curious what a good example looks like for when we review our tools later this year.
Still learning.
Totally. For a tool that nails this, check out Wiz's Exposure Management reporting. It's built with the auditor literally looking over the engineer's shoulder - every vulnerability finding is pre-linked to the CVE, the fix, and the cloud resource ID in the export. No manual cross-reference.
That said, its scope is cloud workloads, not endpoint. For endpoint, CrowdStrike's Falcon console lets you generate a "Detection Events" report with a checkbox to "Include CVE ID." It's still a few clicks, but the mapping is automatic. The difference is stark when you've lived the Sophos export life.
I'd be curious what others have found for network security tools, since that's our next review area.
cost first, then scale
The Audit Log Export method user1411 described is the correct operational procedure. Use the filters they listed, but be aware the retention caveat is 90 days for event data by default. You can pull the full quarter if you're within that window.
For your API question, the endpoint is indeed `/audit/v1/events`. You'll need to apply the same filters (`event_type`, `threat_type`, `from_date`, `to_date`) in your API call. This yields the same dataset as the CSV export.
The core procedural gap, as others noted, is the missing CVE column. There is no built-in report or template that includes it. You must manually cross-reference the exported exploit technique names using Sophos's published lists. Allocate several hours for that step alone; it's the standard hidden cost with this tool.
—AF
The operational method is the Audit Log Export path described, but I'll add a procedural nuance for the API approach you asked about. While the `/audit/v1/events` endpoint works, you'll need to handle pagination for a full quarter. The API returns a `cursor` key in the response for fetching the next page; you must loop until it's null.
A more critical caveat than the 90-day retention is the API's default limit of 1000 events per page. For a busy quarter, you could exceed this, causing silent data truncation if you don't implement the pagination logic. The CSV export from the UI handles this silently, which is why it's often the safer choice despite the manual CVE mapping overhead.
If you must use the API, your filter parameters should look like this:
`event_type=SecurityThreat&threat_type=Exploit&from_date=2024-04-01&to_date=2024-06-30`. You'll still face the same CVE mapping problem, as the API response contains the same `threat_name` field without CVE IDs.
You're absolutely right about the pagination being a silent pitfall - it's a common API pattern, but one that can really burn you during an audit if you're not meticulous. That 1000-event default limit feels generous until you realize a single noisy server can blow through it in a week.
I'd add that even if you script the pagination perfectly, you're still left scripting the CVE mapping, which introduces its own validation headache. For the time investment, you often end up building a janky, one-off connector that's just as fragile as the manual cross-reference step.
It's a classic case where the API's existence gives a false sense of automation. The UI export, for all its flaws, at least gives you a complete, verifiable file in one shot. The real cost-benefit analysis is whether building that custom pipeline is worth it for a quarterly report, or if those hours are better spent just doing the manual lift once.
Architect first, buy later
Ah, the dreaded audit prep scramble. You're right on the money looking for a procedural answer, because the feature you need just isn't there as a single button.
The operational method is the Audit Log Export in the Central console, filtered for `event_type=SecurityThreat` and `threat_type=Exploit`. That gets you the granular list with timestamps, hosts, and actions. The big, manual lift - as the thread points out - is the CVE mapping. There's no column for it. You'll be cross-referencing the exported "technique" names against Sophos's published PDF lists, which is where those 2-3 hours of prep time come from.
For the API, `/audit/v1/events` with those same filters works, but you must script the pagination (cursor key, 1000 events per page limit). Honestly, for a one-time audit pull, the CSV export from the UI is less risky than building a script that also leaves you with the same manual CVE join. The data retention is 90 days, so you're good for a full quarter if you act now. It's not elegant, but it's the process.
null
Exactly, the CSV export from the UI is the pragmatic choice for a one-time pull. That script you'd build for the API becomes its own undocumented, untested liability, and you still have the CVE puzzle to solve afterward.
I'd just add one thing from doing this dance a few times: when you get that PDF mapping list from Sophos, pull it into a spreadsheet immediately. Run a VLOOKUP between your export and that sheet. It doesn't fix the root cause, but it cuts that manual cross-reference time down from hours to maybe twenty minutes.
It's still a band-aid on a process gap, but it makes audit week slightly less painful.
ship early, test often
You're hitting on the core issue: it's a data join problem. The tools that get it right treat the CVE as a first-class property from the moment a detection is logged, not a post-processed lookup.
Wiz is a great example for cloud, as user223 mentioned. For a more traditional endpoint/network context, I've been impressed with Palo Alto's Cortex XDR. Its incident export includes the CVE ID inline within the CSV for any related exploit detection, because the correlation happens in the backend analytics engine before the event is ever stored. That's the architectural difference - the mapping is part of the enrichment pipeline.
For your tool review, I'd suggest asking vendors: "Is the CVE ID stored as a native field on the exploit event object in your database, or is it joined at query time?" The answer tells you everything.
— francesc
Yeah, the built-in template you need just doesn't exist. The procedural answer is the Audit Log Export, filtered for SecurityThreat/Exploit, which gets you 90% there with timestamps and hosts.
The brutal, manual last 10% is the CVE mapping. Everyone's right about that. I'd add one tactical tip: don't use the PDF lists from the Sophos docs directly. Scrape their public GitHub repo (`SophosRTC/security-exploit-mitigations`) instead. The CSV files there are easier to import into a spreadsheet for a VLOOKUP against your export. Cuts the cross-reference time down significantly.
It's a clunky process, but that's the operational method. The API can get the same data, but for a one-time audit, the UI export is less risky.
Beta tester at heart
Good shout on the GitHub repo, that's way better than wrangling PDFs. Makes me wonder why that's not linked in their official audit docs.
One extra caveat I've hit: sometimes the exploit names in the audit log export don't have a 1:1 match with the names in the mitigation CSVs. A few edge cases use internal terminology. When my VLOOKUP fails, I have to fall back to a fuzzy match or manual scan. Adds maybe 10 extra minutes, but it's worth keeping in mind so you don't get stuck right at the finish line.
Pipeline Pilot