Creating a secure firewall policy for a large company

When it comes to a network security policy, there often seems to be a direct tradeoff between security and maintainability. This doesn’t always have to be the case. Even in large organizations, security policies can be easy to maintain if you follow some best practices that ensure they remain clear, intuitive and well-organized.

Ready for change
The business requires on-going changes to connectivity. 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 wind 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 – supported by some vendors.

Easy to troubleshoot for connectivity problems
When something goes wrong, the firewall is often first to be blamed. To make sure that you can determine whether the firewall is the source of a problem, insist on trouble tickets with precise information, such as “Joe’s PC cannot access CRM over HTTP.” If you have a clear problem definition, you can quickly determine which firewalls are involved and find out if they are blocking traffic using log analysis or policy analysis.

Easy to reverse changes when necessary
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. You can do this if you maintain an easy-to-read audit trail of all policy changes with full personal accountability.

Self-documenting and usable by all
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. You can challenge the team periodically by asking “what does this rule do?” or “show me the CRM rules.” Managing the policy must not depend on any one person’s private knowledge.

Easy to learn and understand
When a new administrator comes on board, you should be able to teach him the policy quickly. You should be able 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, even from different vendors
Your policy design should be consistent across the environment. Keep in mind that even if you have a single policy today you may have 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 technologies (e.g., next-generation firewalls).

Well documented
Every rule and important object should be documented. 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.

Justified by the business
Every permissive rule should be there for a reason – or it is just a security compromise. Don’t allow over-permissive rules, even temporarily (unless you have 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). Periodically remove stale rules and objects. You will need some mechanism to identify these, as well a documentation of the business owners so that you can contact them and verify that the access is no longer needed before removing it.

A manifestation of high-level security policy
Last but not least, your 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 that your firewall policies follow a well-defined security policy, such as, for example, a zone-based white list policy. 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.

Share your recommendations for keeping large security policies under control.