Archive for the ‘FireMon Tips & Tricks’ Category

Despite being one of the older security technologies, firewalls are still the most utilized network security control in the enterprise. As Gartner noted in its last Magic Quadrant, “firewalls have long provided the most cost-effective means of protecting vulnerable PCs, servers and infrastructure from external attacks to enable secure business use of the Internet.” One of the many operational challenges in managing firewalls is that business units are constantly requesting new access through the firewall. While most security teams are quick to accommodate a business unit’s request, very rarely do these same teams audit whether a requested access is still required 6 months, a year or even 2 years after the request is processed. Many of these requests are for a temporary access that ends up remaining in the firewall policy for years.

At FireMon, we have seen customer environments where as many as 70% of the rulebase was not being used. These unused rule can significantly degrade the performance of a firewall, and can potentially introduce risk into the environment by allowing protocols or networks access into your enterprise that are not needed. As the NIST guidelines for firewall policy state “generally, firewalls should block all inbound and outbound traffic that has not been expressly permitted by the firewall policy—traffic that is not needed by the organization.” Allowing unused rules to remain in a policy goes against this central tenant and represent an open risk to the organization.

Fortunately, FireMon Security Manager makes it easy to identify unused rules within your firewall policy. Within the list of devices in the Security Manager client, a user can simply right click on any firewall device, select reports and then Unused Rules Report. The pop-up box that appears allows you to specify a date range or previous number of days to show unused rules within that time frame. Users can also select if they would like the report output to be a PDF, Web Page or XML data. Clicking Finish will produce the report, which will show unused rules for both the Security and NAT rules on the device. Security Manager also enables users to setup the Unused Rules Report to run automatically on a daily, weekly,monthly, yearly or custom time frame. This automated report can also be emailed to any number of recipients. A common best practice among many Security Manager users is to have the Unused Rules Report emailed to them the 1st of each quarter showing which rules went unused for the last 90 days, reviewing the access with the business unit that requested the rule (which is identified by Security Manager using the Policy Planner tool) and removing the rule if the business unit has no valid justification for continuing to have the rule within the policy.

By leveraging this simple but powerful report within Security Manager, security managers can ensure that their firewalls are not introducing any unnecessary risk to the organization or negatively impacting the firewalls performance by unnecessarily increasing the size of the rulebase.

A while back, I worked with one of our clients who was put in a tough spot by their external auditors. The auditor flagged every firewall rule that accepted traffic and used the “Any” object in the service column as non-compliant. Our client, in turn, asked us, “How can we quickly redefine these rules with more appropriate access? And how can we do it without interrupting business operations?” The answer we gave them was FireMon’s Traffic Flow Analysis.

Finding Big Rules

We’ve all had those handful of rules that we hate. They’ve been in the firewall for years and nobody remembers who put them there or why. But they all have something in common: they aren’t secure. They allow too much access, auditors hate to see them and no one can justify the access because the uses are too broad. Class A networks in the source or destination, “Any” objects in the service column, and the use of deeply nested group objects are all examples off broad access.

So, why were the rules added in the first place? There are a lot of reasons, but I think the most common one is that the real requirement for access was not well defined, so broad access was given to ensure functionality. It’s certainly not uncommon for security to be the last to know about architecture projects or new systems being deployed on the network, so engineering on a short timeline without all of the information has almost become status quo. Given the high probability of those scenarios continuing to occur, how can we improve the rule set without interrupting normal operations?

Removing Big Rules

FireMon’s Traffic Flow Analysis can help you pare down those big rules into a handful of manageable rules that more correctly represent the access that is required. Once you do that, the business justification for the access will be clear, the business owner can be assigned, and the rules can be managed throughout the rest of their life cycle.

Traffic Flow works by closely watching the access that is in use behind a single firewall rule. Then, using a complex algorithm to determine the common access paths, it recommends how you can define new access. The analysis can be as simple as showing the services used by that rule or complex rule definitions that include the source, destination and service.

Traffic Flow is available for firewall rules as well as ACLs on Cisco routers. It also has some additional uses, such as quickly helping you see what is falling through to the drop rule or creating a policy from scratch by monitoring an accept-all rule.

One of the most powerful features inside of FireMon is our ability to quickly add customized reports or audits to the application.  This takes minutes and doesn’t even require “us” to do it.  Our customers do it all the time.  Don’t believe me?  Take a look at Secure Passage’s Nexus community (https://nexus.firemon.com) where you can find a wealth of these unique reports being exchanged amongst our user community (and some of the sharpest minds in the security space).

The point of my entry here isn’t to showcase Nexus, but rather to tell a story about a recent customer experience.  You may have caught the recent announcement by Cisco last week who was reporting “multiple vulnerabilities” in the firewall services module for its Catalyst 6500 switch and 7600 series router.  Basically, the exploit allowed an attacker to reload a firewall module after processing crafted SunRPC or certain TCP packets.  A repeated attack could result in a sustained Denial of Service condition.  This vulnerability affected Cisco FWSM software version 3.x and 4.x only if SunRPC was enabled (which it is by default).  To learn more: http://www.networkworld.com/community/node/64631

Yikes.

If that weren’t bad enough, this customer had several of these devices under management and wanted to know if FireMon could check for this vulnerability.  The very short answer was yes!  By simply going through the list of monitored devices inside of FireMon and applying a simple audit looking for the version of the software running on that device, and if a certain setting was turned on (SunRPC) we could report to the user which devices should be upgraded or mitigated against.

I guess the real beauty of the story here was that particular audit where a very specific version of software and setting was being checked against, didn’t exist.  However, a similar one did.  By making a five-second change to the criteria of the audit, the report immediately returned the results the user was looking for.  And should this event or one similar happen again, that simple change makes this entire audit absolutely relevant again.

Nice.

Firewall rules don’t get added because a security engineer thinks it would be fun to add a rule.  They usually get added because there was a business demand for new access.  And that request for new access is not always well defined; “I need to get access to the new ERP system”.  Just you or your team?  To just the front end or the back end too?  What kind of access?  Some of these questions may get answered if time permits, but necessity of access NOW may override the perceived luxury of security.

Too often, business needs trump security prudence.  Rules get added to firewalls that permit too much access.  A rule to that new ERP system may allow access from the user’s network to both the front end and back end with ‘ANY’ service.  The access works; the business is happy; but you know security could be better.

So why not just go back and fix it?  Time of course is one consideration.  When do you ever have extra time to improve something that is already working.  A second consideration is your own job.  Security of the network is important, but job security isn’t bad either.  Although refining the overly permissive rules in a firewall is good for security, blocking business access to a critical resource is detrimental to your own job security.  And that is a likely consequence if a project to refine access in a firewall is undertaken without significant care. Read the rest of this entry »

There is an old riddle about firewall management -

Question: What goes in but never comes out?

Answer: A firewall rule!

Most organizations have well established methods and procedures for adding rules into a firewall, but very few organizations have strategies for removing rules that no longer serve a legitimate business purpose.  If you are a firewall administrator, see if you can remember the last time someone in you company called you and said, “Hey, remember that rule I had you add 6 months ago, I’m done with that project now, you can delete the rule.”  Contrast that with how often you have been told, “You have to make this change right now, the business depends on it.”  It’s no wonder firewall policies grow out of control. Read the rest of this entry »

Firewall policies are complex.  Some firewall vendors try and reduce the complexity of administrating firewalls with graphical editors or zone-based administration and those concepts help.  However, the reality of legacy policies, short timelines for engineering changes and staff reductions all lead to the strong likelihood that a large number of technical errors exist in firewall policies and more are being made.

Realizing this gives us a great starting point for detoxing the firewall.  Let’s clean up the technical errors — those configuration elements that could never be accessed based on the policy above.  Hidden rules, obscured rules, covered up objects…all are errors in the policy that can be removed. One of the reasons that I like to start a firewall cleanup with technical errors is that there is no need to collect logs or consult the business because removing those items does not change the behavior of the firewall. Read the rest of this entry »

Requirement 2 of CIP-005 requires access controls at the electronic perimeter. I think most of us read it and see firewalls as a big part of the solution. However, there are implications beyond just putting in a firewall with a good rule set. R2 requires control and documentation of the ports and services that control access to critical items.

FireMon supports R2. If you asked me how FireMon could help meet R2, I’d name at least two features. Rule Documentation is the big feature that lots of energy companies can use to put port/service justification directly on top of the rule. Policy Report, which shows why access is allowed, is useful, too. But I think folks are really looking for the efficiency of Rule Documentation, where that justification information is automatically taken from the change process, and they avoid cost of creating documentation manually.

But if you asked our customers, you might get a different answer. I was working with one of our NERC-impacted customers this week, and they were using a FireMon feature for NERC that I’d never thought of. They looked at R2 and saw the implication that there needs to be some accounting of who has access to those critical assets and what services they are using to access them.

The firewall logs were the obvious answer to the accounting problem, but finding the right logs and pulling the right information was going to be expensive. Enter FireMon’s Traffic Flow Analysis (TFA) report.

TFA inspects a rule and shows which sources are accessing which destinations over which services. We built TFA to help create better rules from ones that are too broad. But by turning the TFA report on for all the rules that allow access to critical assets, our customer can pull an accounting report at any time.

This is another example (and there are a lot) of a great way to use our most popular new feature.