When it comes to a network security policy there often seems to be a direct trade-off between security and maintainability. But I’ve found this doesn’t always have to be the case. Even in large organisations, security policies can be easy to maintain if you follow some best practices that ensure they remain clear, intuitive and well-organised.
The business requires ongoing changes to connectivity, and making these changes is the responsibility of firewall administrators. Your goal as the architect of the security policy is to make it easy for the administrators to find the relevant rule – or add new ones when needed – so that they can provide fast and accurate service. Here are a few guidelines for architecting a policy for maintainability:
- Provide clear documentation for each rule and network object so that anybody can understand what they are for.
- Avoid using the same rules and network objects for multiple purposes – create another rule or object so you don’t end up with rules and objects that do everything but are insecure and impossible to maintain.
- Group rules per business need and document them with a section title, which is supported by some vendors.
The firewall is often first to be blamed when something goes wrong. To make sure you can determine whether it is the source of a problem, insist on trouble tickets with precise information, such as "Joe’s PC cannot access CRM over HTTP". A clear problem definition will enable you to quickly determine which firewalls are involved and find out if they are blocking traffic by using log or policy analysis.
When the security policy is responsible for an outage or is blocking connectivity, you should be able to quickly determine when, why and how the policy was broken and reverse the relevant changes. This is possible if you maintain an easy-to-read audit trail of all policy changes with full personal accountability. The firewall or ACL policy should contain all of the information that is needed to manage it. Do not allow anyone to introduce undocumented changes, not even temporarily. Managing the policy must not depend on any one person’s private knowledge.
When a new administrator comes on board, you should be able to teach them the policy quickly. It should be possible to say, "this is our policy structure" and "this is our process for changing policies", rather than "this rule does this and this rule does that…."
Consistent across firewalls
Policy design should be consistent across the environment. Keep in mind that even if there is a single policy today there may be many more in the future. Firewalls from other vendors may appear because of business requirements such as mergers and acquisitions, cost reductions that dictate a vendor switch or emerging tech (e.g. next-generation firewalls).
Content from our partners
Every rule and important object should be documented, and maintain policy sections with clear names where possible. For every policy change put the relevant ticket ID in the comments field and use a standard convention. Some people like to maintain an object naming-convention, for example: host-10.0.1.30 or net-10.0.1.0.
Every permissive rule should be there for a reason, otherwise it is just a security compromise. Don’t allow over-permissive rules, even temporarily, unless there is a well-defined procedure to correct them later.
Put time restrictions on temporary access flows (different vendors have different mechanisms for this such as Time Objects in Check Point or Rule Expiration in Cisco) and periodically remove stale rules and objects. You will need some mechanism to identify these, as well as a documentation of the business owners so they can be contacted to verify that access is no longer needed before removing it.
Last but not least, a firewall ‘policy’ is not the security policy, it is only a manifestation of a part of it (other parts may be related to end-point security, physical security etc.). Make sure they follow a well-defined security policy, such as a zone-based white-list policy, and be prepared to prove compliance at all times.
In addition, I recommend maintaining a written guidelines and procedures document that explains the policy structure, documentation standards, naming conventions and procedures for change policies.
