| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| I have been asked by my organisation to do a review of the rulebase for their checkpoint firewall system. They have splat management and a number of nokia HA clusters. There are different policy packages for each cluster but on one of the rulebases there are over 200 rules. We hope to add in another 50 rules shortly to allow for new services. I was wondering if there any generally recognised approach to conducting a review of a security rulebase. From reading up on the topic there would appear to be a consensus around placing the most used rules to the top of the rulebase and deleting unused rules. Aside from this, I have read that keeping "any" out of the rulebase is recommended from a security and efficiency viewpoint and being as specific as possible about the sources, destinations and services. Organisation of the rules in section titles I read as recommended as well for presentation. This would still leave a very large number of rules in our rulebase. The question I have is basically is this the way it has to be or is there any additional approach we can adopt? |
| |||
| Having a large number of rules may just be that you have diverse number of connections. Just because it is large does not make it bad. I think you have already answered the question yourself. Generally when implementing rules also comment why rule in and if temporary when it is to be removed. That way can easily see if can be removed. There are also some 3rd party tools that can analyse your rulebase and tell you what rules are not used. They depend upon the Log Analysis to do so make sure that you Log everything otherwise will be told that not used as no log entry. |
| |||
| Also, Eventia Reporter performs this service as well (and it actually works as of R65 HFA_02). __________________ There's no place like 127.0.0.1 |
| |||
| I have done this in two capacities: internal review and managing external auditors. Because firewall policies can be vastly different, gaining insight in to how effective or ineffective a particular rulebase can be difficult. I find that the most effective thing to begin with is determining the purpose and expected output from an audit. Auditing a policy to make it more efficient will have a very different scope than an audit focused on security best practices. Working with management to determine this will help you set expectations for the deliverables once the audit is complete. Once the purpose has been defined you will be able to focus on the output. By setting output goals you can get an idea of the approach you will take to gather the necessary information. Here are a few examples: 1. Efficiency: Determine how you can make your rulebase more efficient by removing unnecessary rules, combining rules, or relocating the most used rules. I think you can now do this with Eventia, but it can also be accomplished by third-party systems. A few I know about include firemon(secure passage), most log management products(Log Logic), and even some homegrown Perl scripts. 2. Security Policy Enforcement: Determine how effective your firewall policy enforces your overall security policy. This tends to be more difficult, as it requires matching policy to practice. If you are lucky, your company has set out what services and practices that are allowed/disallowed. Matching this to a firewall policy is relatively easy, though time consuming. The unlucky will spend time laying out the black and white services and, through the audit, documenting the exceptions. 3. Change Management and Compliance: Determine if the firewall policy and procedures are compliant with internal and external best practices. While this is similar to the previous topic, the deliverables tend to differ. Your goal here is to determine if the changes made to the policy are reflected in the proper control systems. I find an external tool like firemon or securetrack works well in this area, for day to day operations as well as audits. While both are expensive they are a must have for a large environment. This can be done manually using SmartView Tracker, but it will take a lot of time. Once this is complete, the next step is to build a list of "actionable" data. This means translating your findings to actions to be taken. An example: Finding: * Found 5 rules that offer the same service. Must have been done by a few different engineers a long time ago and never cleaned up* Action: *Combine rules 14, 15, 75. Remove rule 132.* Finding: *Changes are not tracked appropriately* Action: *Develop an RFP for an automated change monitoring system* Building a matrix of these items can help you prioritize these changes. Some are as simple as adding/removing rules. Others are as complex as adjusting the change control process or adding a new management system. Being able to graph complexity and importance will make prioritizing a simple task. It will also be helpful when presenting your findings to management. The last thing is to make sure this process is repeated on a regular basis. Plan to fully audit your policies on an annual basis with spot checks on a quarterly basis. If this is being done externally, make sure the cost is in your budget ahead of time. While this is not a complete list, it should help you on your way. lodown |
| |||
| Each case is a case, but here are some things I usually go by: - I use one color per subnet/area and make sure all devices from that "area" all have the same color. This helps greatly in identifying objects and "reading" rules. - Have a naming policy for objects and always write good decent comments - Comment all rules and put a date of removal/review on temp rules, so they don't become "permanent temp" rules - Consolidate and optimize rules regularly - Have strict rules. Avoid using "Any" and if you really need "Any", avoid having 2 "Any" in one rule. (unless it is a drop :) ) |
| |||
| Have a look at Tufin SecureTrack - Firewall Operations Management and their SecureTrack product. It has a significant Policy Analysis and Audit report function in the latest version, as well as rule and object utilisation reports. OPSEC certified, and does a bunch of other cool stuff. |
![]() |
| Thread Tools | |
| Display Modes | |
| |