We're in the early stages of evaluating NGFW add-ons for our hybrid environment (mostly Azure, some on-prem). With upcoming SOC 2 and insurance renewals, the requirement for granular application-level reporting and filtering is getting more specific. The classic firewall logs just aren't cutting it for the "show us your controls" meetings.
I've been testing Zenarmor (Sunny Valley) on an OPNsense box in a lab. The application visibility and category-based policies are impressive for the cost, but I'm digging into the compliance/logging side.
My main questions for anyone using it in a regulated space (HIPAA, FINRA, SOC 2, etc.):
* **Audit Log Integrity:** How are you handling the export and immutability of the policy/audit logs? Are you piping them to a separate SIEM? I'm looking at the Elasticsearch integration, but curious about real-world setups.
* **Policy Change Workflow:** Is there a sane way to implement a change-request-ticket-to-policy workflow, or is it mostly manual admin logins?
* **Session Details in SIEM:** When you forward logs, do you get full application/URL details, or just the base connection info? Trying to see if we can retire a separate web filter.
Here's a sample of the log structure I'm seeing in Elastic, which is pretty useful:
```json
{
"event_type": "session",
"app_category": "Business Systems",
"app_name": "Microsoft 365",
"policy_name": "Finance-Dept"
}
```
Any gotchas or lessons learned would be super helpful. The pricing is attractive compared to some monolithic NGFW upgrades, but I need to be sure it can stand up to auditor scrutiny.
--diver
Data is the new oil - but it's usually crude.
On your question about session details in SIEM, we had a similar goal of retiring a standalone proxy for compliance evidence. The Elasticsearch forwarder does send full application and URL categorization details, not just IP/port tuples. However, the field mapping can be a bit flat; you'll want to build a custom index template to properly structure the `app.category` and `app.subcategory` fields for meaningful dashboards. We found the user agent and threat intelligence fields were also passed through, which helped.
For audit log integrity, piping to a separate SIEM is non-negotiable in our view. The Zenarmor database on the appliance itself shouldn't be considered an immutable source. We use the syslog forwarding (not just Elasticsearch) to a secured collector, where logs are hashed and timestamped before entering our chain-of-custody log system. This gives you a verifiable record for when a policy was changed and by which admin account.
The policy change workflow is the weakest link from a formal SDLC perspective. It's largely manual admin logins, as there's no native ticket integration or pull from a Git repository. We've scripted around this by using the REST API to dump policy configs after changes and tie them to our change management tickets, but it's a workaround. If your auditors are strict about change control, this will require additional documentation effort.
Latency is the enemy
Piping to a separate SIEM is the baseline. The question isn't if, but how you prove chain of custody and prevent tampering from the OPNsense host itself.
If your collector is just another VM in Azure, you've moved the problem. The syslog forwarder is useless if the source host is compromised. You need a write-only, immutable sink, like a managed log service with a locked retention policy. Don't build this yourself.
On the workflow, it's manual. There's no ticket-to-policy integration. For SOC 2, that's a gap. You'll need to document a manual change procedure with approvals and then correlate the admin login audit log to the ticket. It's a process workaround, not a technical control.
Least privilege is not a suggestion.
Good questions, and you've hit on the main compliance friction points. On your first point about audit log integrity, the comments about a separate, immutable SIEM are spot on. For regulated environments, you should consider that pipe a one-way street from the moment the log leaves the OPNsense host.
The manual workflow for policy changes is the bigger hurdle in my experience. As mentioned, there's no direct integration, so you're stuck documenting a manual procedure. For SOC 2, we had to explicitly map our ticketing system's approval record to a screenshot of the Zenarmor admin audit log entry for that change. It's clunky, but it passed muster as a documented control. Just be prepared for that extra overhead.