A firewall change can take five minutes, but understanding what went wrong three months later can take hours.
I have been looking at how small teams document changes to firewall rules, VPN settings, DNS records, administrator accounts and access permissions.
In many companies, the record is only a short ticket saying something like:
“Port opened for the new application.”
That may be enough when everything works. It becomes much less useful when there is an incident, an unexpected outage or a question about who approved the change.
A practical change record could include:
- the reason for the change
- the person who requested it
- the person who approved it
- the administrator who applied it
- the date and time
- the affected device or service
- the configuration before the change
- the configuration after the change
- the tests that were completed
- the rollback method
- the final result
The difficult part is deciding how much evidence is enough.
Saving a full configuration export before and after every small change can create a large amount of data. On the other hand, keeping only a ticket description may not provide enough information to investigate a problem later.
I work with management system documentation and maintain isochecklist.com. I have collected some background information on ISO 27001 information security management. It is my own site and I am linking to it only to explain the governance and evidence side of the question. It is not a technical firewall guide.
For people working in security operations, what has actually proved useful after an incident?
Do you normally keep:
- configuration snapshots
- command history
- screenshots
- ticket approval records
- SIEM logs
- Git-based configuration differences
- all of the above
I am especially interested in approaches that are realistic for small teams and do not require a large enterprise change-management platform.