Creating a Secure, yet Manageable Firewall Policy for a Large Company – Firewall Expert Tip #10.

When it comes to network security policy, there often seems to be a direct tradeoff between security and maintainability. I’ve found this to be untrue. Even in large organizations, security policies can be easy to maintain if you follow some best practices that will ensure that they remain clear, intuitive and well-organized as they grow.

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. You can do this with the vendor’s documentation capabilities and if you have Tufin SecureTrack, you can use Rule Documentation to add descriptions to individual rules, or groups of rules.
• 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. You can find and tighten overly permissive rules with SecureTrack’s  Automatic Policy Generator (APG).
• 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 by analyzing logs or the security policy. With SecureTrack, you can check this quickly with a Policy Analysis query. It identifies relevant firewalls and rules automatically.

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.  It’s difficult to maintain an accurate audit trail without an automated change management solution. If you do go for an automated solution, make sure that it supports real-time policy tracking, which will ensure that all changes are recorded along with the name of the person who made them.

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 Vendor

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).  SecureTrack provides a central, unified view for all leading firewalls. You can use SecureTrack to assist daily firewall operations as well as enforce security policies and business continuity policies across your firewalls. Even better, you can implement a Security Change Automation system such as SecureChange Workflow to proactively implement corporate policies across all of the network devices in your organization.

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. SecureTrack ticketing integration can link ticket IDs in rules and objects to the originating request in any web-based ticketing system. You can correlate a ticket ID with specific changes, even across firewalls. The Best Practices report supports enforcement of object naming conventions.

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, such as SecureTracks’ Rule and Object usage report, as well as documentation of the business owners so that you can contact them and verify that the access is no longer needed before removing it. Some vendors enable you to document business and technical owners for rules, and if not, you can do this with SecureTrack rule documentation.

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. If you have an automated solution like SecureTrack, define your corporate security policy (black or white list) along with real-time alerts so that you will know about violations immediately. 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.

Reuven

Don't miss out on more Tufin blogs

Subscribe to our weekly blog digest