Configuration / Rule Set Scheduled Export for SOC2 / ISO27001 Audits?

[Toivo]

I'm looking for experiences and suggestions.

We're subject to SOC2 / ISO27001 audits, where the auditors want to know what has been changed in a firewall configuration or rule set. Specifically things like "what rules were added, changed, or deleted in the last year?" or "what configuration options were changed last year?"

The challenges we're running into here are:

• The Panorama configuration history doesn't go back far enough to allow for a diff between a config now and a year ago, and is way too messy with all the random reorderings and additional elements from firmware upgrades to be useful.
• A simple list or export attached to a control test is not sufficient evidence for auditors; they want to see an export of a firewall rule set in the past in some relatively immutable form, such as a PDF saved in a repository with timestamps/version control.

When asked how other enterprises solve this requirement, the response was that most do it manually. This is very challenging considering our staffing levels, and deeply offends the engineer in me on a philosophical level.

How are others dealing with providing ISO27001/SOC2 audit evidence on firewall changes? What works / what doesn't?

Is there a way to schedule a PDF or CSV export of the rule set the same way you can configure traffic log reports or configuration backups?

Is there a way to fetch or trigger the same via an API?

Overall the corporate policy is to not do customization or custom coding, Ubuntu is not an allowed distribution, and same goes for any OSS software (such as Expedition) which does not have a commercial support contract with SLAs. This obviously constrains us pretty heavily as well.

[BPry]

@Toivo,

I keep all of my configurations in Git and manage any changes directly in the XML configuration file itself. That's not something most people are willing to do, however in your case I'd recommend that you configure a nightly export of the configuration and store that in a Git repository. You'll have your history and all associated changes tracked for you automatically when it comes time to an audit. 

This method above has been what I've introduced at multiple organizations when audit needs dictate a paper trail of all of the changes. The nightly export in a git repo gives the auditor all of the configuration history they could possibly want, and since you can download past versions you can easily do a diff of the file to see what was modified. 

Alternatively, you could track the actual Diff itself in whatever you're using for change management. I have a client that forces that in their Jira instance for any and all changes. Personally I find this to be incredibly annoying and a huge pain and would recommend Git whenever possible, but this works for them since they can just search for the last year's change tickets with a filter and provide every single diff for the change. 

This makes the auditors job really easy, but I'd argue that it's annoyance to actually get things done isn't worth it. The auditor has also always wanted to see actual configuration files and not just diff statements since the comments in the Jira ticket aren't really proof that something wasn't modified outside of change control.