Archive for the ‘Firewall Management’ Category
Misconfigurations: the Firewall’s Greatest Threat
Gartner recently published a new research note, “One Brand of Firewall Is a Best Practice for Most Enterprises”, that advocates exactly what the title states: that consolidating to one brand of Firewall is a best practice for most enterprises. This is a position that certainly all of the major firewall vendors will welcome, and one that will likely stir-up a significant amount of debate. Deploying two different firewall vendors has long been an accepted best practice within network security, and the majority of customers we have interfaced with here at FireMon certainly follow that model. While I will leave the debate on this to other blogs, one statistic that was noted in the research note caught my eye.
Gartner noted in the research note that ” Through 2018, more than 95% of firewall breaches will be caused by firewall misconfigurations, not firewall flaws.” We at FireMon could not agree more. Previously on this blog, we have highlighted that configuration mistakes not only represent the risk of impacting network performance, but more importantly represent a potential risk to the network. Firewall admins could potentially (and have done so in many environments) stop a revenue generating service from working properly by incorrectly configuring a firewall policy. The bigger threat though is the potential of allowing connectivity from outside of the network to a portion of the internal network that should not have access. As Gartner noted in the research note, “Diligence in patching firewalls, monitoring configuration and assessing the rule base is required to maintain security.” Misconfiguration of your firewall policy is a serious security threat, and regardless of your opinion on the one firewall vendor versus two firewall vendor debate, a tool that automates the monitoring, configuration and assessment of your firewall rulebase is required to maintain effective network security. FireMon Security Manager can provide that automation for you, and help to eliminate your firewall’s greatest threat.
The Firewall is the Most Successful Technology
Roger Grimes and I have engaged in a very interesting conversation around the necessity and value of firewalls. Yesterday I took issue in my blog post with Roger’s initial claim that the firewall is dead. In response, Roger continues his argument in his post, The Firestorm over Firewalls.
Roger seems to have capitulated the argument on ineffective management and instead doubled down on two core points:
- 99% of all attacks are client-side initiated and the firewall is ineffective at protecting against these attacks
- The fact that the industry is not more secure is proof that the firewall is worthless
I still take significant issue with the argument that 99% of all attacks are client-side and Roger’s “proof” that anti-virus vendors block a lot of stuff is not compelling to me. Remember firewalls “block” a lot of stuff too with billions of logs of dropped traffic generated every second world-wide. Neither of these points is sufficient to make or dispel the 99% claim. The Verizon Data Breach Investigations Report I referenced is also not perfect, as Roger points out, as it only covers a minority of all attacks worldwide. But it is the best source I am aware of, so I think it is still worth referencing. And pointing to a sample graphic ( on page 8 ) meant to describe a documentation standard as “proof” that client-side attacks are responsible for all breaches is not very compelling either. Especially since it was not written to support this point in any way. However, even if we do acknowledge Roger’s “proof” graphic on page 8, take a look a the paragraph describing it that claims an egress filter (firewall) could have prevented the breach and it seems to dispel Roger’s obituary of the firewall.
But let’s set statistics aside. I imagine there are plenty of other people who can more credibly respond to Roger’s unsubstantiated claim about 99% of attacks are client-side. And, I don’t mean to argue that client-side attacks are not an issue, I simply mean to claim they are not the only issue.
Instead, I would like to hypothetically accept Roger’s postion that 99% of all successful attacks are client-side. I would argue this change in attack vectors through the years strengthens the case that a well-configured firewall is an effective security control. It is a matter of attackers coming in through the open window instead of the closed door. The growth in client-side attacks suggest the direct attack is being successfully thwarted by the firewall and less effective solutions are being exploited.
The great thing about a firewall is that it employs a positive security model where only what you decide to allow is permitted and everything else is denied. When managed well, it makes it a great security solution. In contrast, malware detection and anti-virus software employ a negative security model where everything is allowed and only known bad attacks are denied. This creates a horrible cat and mouse game that the attackers seem adept at winning by staying a step ahead of the latest signatures. Which begs the question, if Roger’s argument is that client-side attacks are the real problem and the fact that we still have security problems is justification to “kill” a technology, why does he pick on the firewall. Shouldn’t he instead have called anti-virus or anti-malware or some other client-side technology dead instead? The firewall, according the Roger’s own logic, is the one technology in the game that is working.
The firewall isn’t dead. In fact, I think Roger’s arguments strengthen the case the firewalls are working. Are they perfect, no. Are they sufficient to solve all the security problems, no. Should we get rid of them because they are not perfect, NO!
And this gets to the heart of the matter: the fact that there remain security issues in information technology is not a matter of one technology working or not. It is not justification to call an effective technology “dead” because it doesn’t solve everything. When effectively managed, the firewall is a very effective security solution. Additional capabilities in NG Firewall technology continue to make it a relevant and central part of a security solution. It should not be considered THE solution, but it certainly shouldn’t be discounted either.
The Report of The Firewall’s Death is Greatly Exaggerated
Today Roger Grimes posted an article on InfoWorld about the overdue death of the firewall: Why you don’t need a firewall. His case rests on two primary arguments: 1. The firewall doesn’t protect against modern day threats, specifically client-side vulnerabilities and the fact that all apps run over port 80 and 443 that can never be blocked in the firewall and 2. The firewall is managed so poorly that it causes more problems than it solves.
Let’s separate these two points to more logically discuss each, starting with the value of a firewall in today’s threat environment. I take significant issue with his statement that, “Today, 99 percent of all successful attacks are client-side attacks”. This is not substantiated by any research for good reason; it isn’t true. The Verizon Data Breach Investigations Report actually discusses successful attacks in significant depth and completely invalidates this point. It reports that 81% of all attacks and 99% of lost data is a direct result of “Hacking”. It goes on to specify that access to remote services (e.g. VNC, RCP) “combined with default, weak or stolen credentials” account for 88% of all breaches. The assumption that 99% of attacks are client-side is dead wrong.
With remote access to services remaining the greatest attack vector today, firewalls still play a very significant role and are changing dramatically. It would also seem that Roger is ignoring new advancements in firewall technology. NextGen firewalls are specifically adept at helping prevent the client-side attack. No longer is port 80 and 443 an open highway of access through which everything can pass. User-based and application-based policies permit effective control of outbound access.
Roger’s second point, on ineffective management, is something which I agree is a problem, but don’t agree with his conclusion. His argument that ineffective management, where rules are created that permit nearly all access renders the firewall useless, is absolutely correct. Ineffective management that leads to poor configurations is a problem that can turn the best firewall technology into nothing more than a router passing all traffic. But his conclusion that this means the firewall should die is a really bad leap in logic. Poor management is not cause to kill the technology. Instead, I propose more effective management.
FireMon has been dedicated to this very idea of better firewall management for over a decade. Ineffective firewalls are not a caused by bad technology or incapable administrators. It is a problem with management. A stream of 1,000 logs per second won’t make any sense if a human tries to process their meaning while staring at a screen, but with some automation of log analysis, they can provide a wealth of information. 500 complex rules in a single firewall policy may be nearly impossible to evaluate to understand what access is truly being allowed, but with a powerful policy analysis tool, it is a trivial exercise. Even Roger’s example of a poorly defined rule with “ANY ANY” defined due to missing requirements is a solvable problem with the right tools. FireMon provides a powerful Traffic Flow Analysis tool that analyzes traffic flowing through overly-permissive rules permitting retroactive correction of these problematic rules.
The firewall is not dead and won’t be. With next gen capabilities and effective management – which is possible and available today – the firewall will remain a critical component of security solutions forever.
Improve Firewall Performance & Security by Removing Unused Rules
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.
Dissecting Big Firewall Rules
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.
Virtualization and Firewall Management
Chris Hoff (@beaker) had a blog post up recently on his Rational Survivability blog, once again making the call for automating security (and compliance and audit as well) in both physical and virtual environments. This is a cause that Hoff has long championed and is certainly a worthy goal.
Chris believes that leveraging APIs is one of the ways we can help accomplish more automation. He pointed to an example of leveraging APIs in VMware that was written by Richard Park of Sourcefire and deals with automating via Perl and APIs, firewall functions in a VMware virtual environment to accomplish things such as:
- List the current firewall ruleset
- Add new rules
- Get a list of past firewall revisions
- Revert back to a previous ruleset revision
The idea of virtualized firewall ruleset management is of course something near and dear to us here at FireMon. We have thought long and hard about virtualization in general and virtualization of security in particular. Of course this is something that we think FireMon’s product suite will have deep capabilities around, especially as more network operations move to virtual environments.
Network management in the physical world has been sorely lacking in general and security device management even worse. Frankly, this is why FireMon has been so successful. The virtual world, as Hoff tweeted, does promise some relief in this area.
But fundamentally we believe that automation using API’s and such are only part of the answer. How do you script in context? Park’s post discusses the ability to programmatically create rules, which is cool, but the framework to automate change is much bigger than technically creating the rule. What rule to create? Who has permission? What defines the rule to create? What is the process to create it? Firewall administration tools have offered user friendly ways to create rules yet corporations routinely create the wrong rules, excessive access and then ultimately fail to manage them long term.
Perhaps when it comes to managing firewall automation and firewall management, just as in the physical world, in the virtual world the ability to automate in and of itself does not necessarily solve your issues.
Don’t get me wrong, some things are logical for automation … for example, if you are using VM’s to scale, each time you bring up a new VM for the same purpose as another VM, you may want to define the exact same policy, but for the new IP of the new VM. This makes sense, is very repeatable and is perhaps the only way to achieve the security and operational goal of virtualization.
But there is a lot that has to go into security management, both physical and virtual. Here at FireMon we spend a lot of time learning and thinking about it and we see an opportunity to address some of these challenges.
Advancements of Next Generation Firewalls
It seems every day another security vendor releases their version of the NextGen firewall. While Palo Alto Networks staked their claim to the NextGen firewall some time ago, everyone from Check Point to Fortinet have recently announced NextGen firewalls.
FireMon recognized the value and power of these firewall advancements and has been a partner of Palo Alto for some time, focused on providing management for this new technology. While NextGen firewalls offer significant and important new capabilities to the firewall technology, the management problem remains. No matter how great the technology, if it is ineffectively managed, it will fail to solve the problem.
There are a couple key advancements in NextGen firewalls worth noting: user-based access policies and application intelligence.
While most firewalls have provided user access control by requiring secondary authentication at the gateway, this was completely disjointed from the existing directory infrastructure and complicated to manage. As a result, it was not often implemented. NextGen firewalls, through directory integration, have the potential to change access management from IP-based to user or user group based access. This is a huge advancement, changing the paradigm of IP access control to user control. And in a world of mobile and wireless devices, this makes access control much more dynamic and effective security.
Application intelligence and the incorporation of that intelligence into the firewall policy helps address the reality of web applications and dynamic protocol / port use in malware and applications. Access policies can now be managed by application or application category. Not only does this address the desired control application use in the enterprise, it can help address malware that makes its way into the enterprise in any form (on USB drive, laptop, phone, etc). If the policy is effectively managed, malware that used to freely tunnel across open ports out of the network and potentially enable backdoor command and control capabilities will be denied, blocking a critical security issue.
But NextGen firewalls can’t solve the problem of poor management. Even these new capabilities don’t magically solve the management problem. In fact, in many ways, they create new problems in need of solutions. I am a big proponent of this advancement in firewall technology and we are excited to offer solutions to help address these new issues. Be on the lookout for a few posts addressing these issues and FireMon’s innovative solutions to help organizations manage the NextGen firewalls.
Sony’s Interesting Take on Firewall Management
I have to admit, like most of you I was amazed to hear that in regard to the recent breaches on the PSN, Sony did not have a firewall in place. I guess one could say that is one way to solve the firewall management issue.
All kidding aside, I could almost understand not patching or updating their Apache software. Patching and keeping software up-to-date is a task that many organizations don’t do a great job of even though there are some great solutions out there. But putting in a firewall?
The most recent data I’ve seen says firewalls are installed in well over 95% of network installations. With even home cable and DSL routers having firewall software installed, I always assumed the small fraction of networks without firewalls had to be those small installs tucked back in some out-of-the-way corner. To think that a company the size of Sony would forego firewalls is mind boggling!
So, why would Sony not put a firewall in place? I would think it is a management issue (I know I am a bit obsessed with the “security needs management” theme lately). But, the same people who didn’t comment for almost a week after this incident, who have repeated incidents and breaches, who installed a root kit on their CDs a while back, just don’t seem to get the whole internet security/privacy thing.
Here is the lesson for the rest of us: Sony is going to pay dearly for this, I’m afraid. This could be a case that the authorities and courts use as an example. A defendant with deep pockets, sensitive financial data lost and it appears a negligent attitude and track record. I don’t think anyone is going to want to be the next Sony.
Go one step further though. Just putting a firewall in place is not enough. You need firewall analysis and firewall management if your investment in a firewall is going to be worthwhile. Just don’t stop at the firewall. Remember, security needs management!
“Real-time” … It’s about time!
I guess what they say about “what is old is new again” really is true, at least in the world of security marketing anyway.
More than 10 years ago when we first started developing FireMon, one of the core features that we thought any solution in firewall and policy management had to have was real time detection and management. Over the ensuing years, as we layered more and more functionality into FireMon, we have never swayed from that core belief and so real-time detection and management remain in the product today.
After pioneering the firewall management and policy management space ourselves for a time, about 4 or so years ago a few new kids on the block came into the market. While it would be nice to keep a market all for yourself, competition is inevitable and in some ways we welcomed it here at FireMon because it would drive to us to be an even better product and company.
One of the quirks that we noticed with some of the competition is that they did not seem to subscribe to the real time mantra. Instead they used a polling technology that didn’t give you the detection in a real-time mode. Frankly, we thought this was probably a mistake and it would be only a matter of time until they realized that real-time detection and management was a must.
Well, it only took them 4 or so years and now at least one of our competitors is touting “real-time detection.” We say, “real time”? It’s about time!
But that’s not the point I’m actually trying to make. At a time (no pun intended) when the security industry as a whole is being tagged for a lack of innovation, this type of me too technology being touted as something revolutionary just adds to the “innovation is dead” talk. It is cheap marketing at its worse to hold this up as something new when in fact it has been in the market already for years.
Our customers, the security industry and the media deserve better. Instead of rehashing old technology with a new marketing twist, we should be really innovating to better serve the market and make us all more secure.
Security Needs Management – Firewalls Are Desperate for It
Two weeks ago I was writing about what we were hearing from customers while I was at the Infosec Europe event. At the conclusion of that post I wrote about the consistent theme we hear at FireMon over and over again is that “security needs management.” I wanted to return to this theme and explain more of what I mean and why I think it is so important.
In security there are currently something like 1,200 different companies offering security products and technologies. The array and scope of these security solutions is dizzying. But the consistent thing across them is that security is seldom–I would argue never–a “set it and forget it” endeavor.
The environment that we operate in is constantly changing. The threats are constantly evolving. If you think that your security posture and settings of last year, last month or even yesterday is enough to protect you, you are sadly mistaken.
Specific to firewall management, it amazes me how firewall rules stack up month after month, year after year, without being managed and cleaned up. Often times when I speak to a new customer I will speculate how many firewall rules they have and how many are still relevant. The ratios are usually pretty bizarre, approaching 40% of rules not being actively used. There rules are no longer relevant, no one knows why they are there or what they are needed for. Unfortunately, the risk of affecting business is usually enough to prevent them from taking corrective action. In a very real way, they are accepting extra cost, effort and risk out of fear of disrupting the business.
This trade off is understandable, considering that a firewall administrator is much more likely to lose their job over disrupting critical business than they will by neglecting these old rules. But this is not sufficient justification to accept this status quo. There is a solution to address this problem.
FireMon will analyze and identify these rules relatively quickly. Understand which rules are unused, which rules are too broadly defined and which rules are in need of optimization. With this information, a firewall administrator can confidently cleanup a firewall policy without the fear of losing their job.
Of course, firewalls are not the only security technology in need of management. The demands of a successful information security strategy demand that your security policies, processes and most important your security technologies be constantly managed. I will continue this discussion in future blog articles.

