Documenting Firewall Rules
For years, firewall managers have been required to justify why a firewall rule was added to the rule base. In the past, lots of us met that requirement by putting the change control ticket number in the “comments” column of the rule. That method worked for a while, but now that regulations like PCI and NERC require firewall managers to produce the full documentation multiple times a year, we need a new answer – one that does not require days of manpower. One that will survive the next time we change ticket systems (and yes, we will change ticket systems… again).
As security professionals, we don’t hold the responsibility for the risk that any access poses, the business leaders do. But we are responsible for advising on risks that are incurred and presenting the information on why our risk posture is the way it is.
So, explaining our access in terms that the business can understand is critical. If all that we know is a technical definition (like some internet IP address has access to some internal server using SSH), we don’t know very much. But, if we capture the justification for why that rule was put in, then we know “a consultant needs remote access to patch a critical application vulnerability.”
The second example shows the information our businesses need to make good risk decisions. It also gives us the information we need to ask the right technical questions, like, “Does that consultant still require access?”
Spreadsheets & Databases Don’t Work
I know a lot of companies have been documenting their firewall rules with spreadsheets and databases. Those are good point solutions, but they don’t scale for two big reasons: the rules move around, and the updates are still manual.
Firewall rules move, so tracking them based on rule number or position does not work. If you’ve tried this and created documentation, and then revisited that documentation a month later, you can barely recognize the work because the rule base has changed so drastically.
The manual nature of spreadsheets and databases is problematic as well. Updates are often made as an afterthought at end of the change process. These manual updates are difficult to enforce as integral parts of the change process, and so they remain inconsistent afterthoughts.
FireMon knows that good documentation is the cornerstone of firewall management. Making a decision about when to keep access in place or take it out is rarely a purely technical decision. Easily and quickly knowing who that access supports and what the access is providing is the basis for making any good decision.
FireMon’s solution integrates with the appropriate data sources (like change management and vendor administration tools) so that you can create documentation naturally, inside of a normal business process. It tracks the rules as they move up and down the rule base and keeps the documentation tagged to the right rule. And it fully reports on the data, including identifying those changes that were not documented.
From my experience, spreadsheets can’t fully report on anything. If yours can’t either, learn more about FireMon’s rule documentation capabilities at http://www.firemon.com/ruledocumentation.aspx.