When it comes to documentation, they need to start putting together a basic command manual. With Cisco, you can look up a command and it gives you examples of three or four different ways that command can be used. It tells you how to put it into the GUI and the CLI. FireMon does need to start doing that. Right now, I use their tech support for that. They give me a command and I create my own book.

We like that it is able to draw the network's topology. However, because it can't see certain things, it doesn't draw the full story. However, it is still extremely helpful. We also have asymmetric routing, which causes a challenge.

FireMon could improve its end-user practices. As an end user, I am just trying to catch up on all the alerts. There are so many, and you still have to go through them and document what was found. 

FireMon could be made more user-friendly when it comes to creating filters or conducting traffic analysis.

One way FireMon could be improved is to open up a little bit. Our team is pretty Linux-savvy and when we're troubleshooting on our own, we're limited by the way the backend is locked down. For example, if we're running into issues with a device not being read properly into the system, we have to go offsite and this doesn't give us the answers we want. We have to wait to create a ticket.

I think that having a more open system and providing documentation for it would be helpful for users like us. We are pretty adept and can navigate through the Linux software that the on-premises FireMon is based on. It would help us in the long run.

Again, having a more open system that we can operate using our own scripting and automation would be useful. The API is there, which helps a lot, but a more open system would let us better dig into issues.

We have not used the Policy Planner but even so, we have identified areas of improvement with it during our testing. For example, it could be better when it comes to ease of integration or ease of policy automation. Another problem is that there is a console where it has too many options and is not very straightforward. Essentially, controlling it could be made more seamless.

Some of the things that you want to do in FireMon are not exactly straightforward, like creating certain reports or controls. Some of the functions could be a little more user-friendly, such as creating certain filters.

For example, I was trying to do a traffic analysis and it can be a little tricky trying to change your firewalls on that profile. You almost have to create the entire thing over again. So there could be some enhancements in the user-friendliness.

While I like the reporting, I think that has the biggest room for improvement. Right now, as a user of FireMon, if I create a report, I am the only one who can see it inside FireMon. If someone on my team creates a report, they are the only person who can see that report on FireMon. It doesn't matter if you're admin in FireMon or not. The way we have to do it now is that we have created a service account user and that service account user runs all the reports. This way, all the reports, which are running, are just run under a single user so we can always access them. This definitely needs to change so users can see other users' reports or we can share reports within FireMon.

FireMon could improve their support for individual vendors. There are features that are specific to Cisco Firewalls that are not supported in FireMon. That changes a lot because they do release updates pretty regularly. However, if you are using Check Point, and that is what you use as your firewall, and you don't use Cisco Firewalls, then all the features for Cisco just aren't really worth it to you. So, FireMon could improve by making sure that they have full coverage for all the vendor specific uses.

It doesn't yet handle our firewall brand very well and some of the complexities that exist in a very large organization like ours. For example, it doesn't handle network address translation very well for cleanup and it doesn't handle nested objects very well for cleanup. It does unused-firewall-rule cleanup pretty well, but we have had to do some extensive modification because it sometimes gave us false positives. It would identify a firewall rule as unused when it really wasn't unused, due to the nature of how Palo Alto works and how FireMon works. That has required some manual workarounds.

I also wouldn't say the solution automatically warns before new firewall rules, or changes to existing ones, violate compliance policies. Not totally. When a change request comes through, it runs through the FireMon process and if it is a high-risk situation, FireMon will flag it. It then requires manual intervention or manual evaluation or correction. Other than that, we work from a monthly audit report that runs to flag any rules that are high-risk. We want to streamline our operations and make them more effective and automated so that high-risk requests are filtered out and validated automatically or semi-automatically, prior to implementation.

We're working on automating the request process, but we're at a standstill right now because FireMon doesn't handle Palo Alto attributes very well yet. It's very Check Point-centric. We've had limited success with automating, as a result. They need to be able to handle Palo Alto firewalls better. For example, they don't do App-ID very well.

It comes as a Linux appliance on a server and we're not a Linux shop, we're more of a Windows shop. It would be great if they could automate or integrate the backups into it and other things through their GUI interface, just to make the management of Linux a little more transparent.

We have had some stability issues that are affecting operations. We rely heavily on this solution and if it isn't working then we have to create rules manually.

The current health and monitoring of the devices is atrocious. I know of several engineers within the company to whom I've mentioned this to and they say, "I know, I've been telling the devs that." They would back me up on my statement.

Here's the bad part, and it's hard to articulate without having like a visual that you and I are sharing. But imagine you have a list of 200 devices, and you can grade each of those devices as either green, yellow, or red. However, there might be three different reasons for you to go to red, or eight different reasons to go to yellow, and all of those things could be combined. As long as all of them are good, that's the only way that you're going to get green. Out of all those categories, I only find one or two of them that are, perhaps, pertinent. I only care if it's not communicating at all, or it hasn't communicated in the last 48 hours. If the last time that it pulled down information it took three minutes instead of one minute, I don't care about that. 

The way that the health and monitoring works right now is that for all these devices, instead of breaking out all those different things, or allowing me to judge what I think is pertinent or not, I have to see the lowest common denominator. I might have 40 percent of my devices saying that they're in a critical state, when in reality, according to my standards, maybe only five percent of them are. I don't have the time to sit here and click on a dropdown and dig into 100 different devices every day of the week. Essentially, because of the way it works right now, I don't resolve something until I've become personally aware that a firewall isn't communicating with FireMon at a given time.

It's not something that is optimized so that an engineer can run a report, take screenshots, and make a little run-book to hand over to level-two support and say, "Here, you guys do this every day as a repeatable process. Make sure that if we have any issues, we open tickets about them." Right now, the overhead of conducting a thorough day-to-day assay of the health of our environment would take several hours. Functionally and logistically, we just can't accomplish that goal right now.

To my knowledge, there's no cloud component to FireMon whatsoever. We're on the hook for any updates to versioning of the operating system or the application that runs on the operating system. It would be nice if it was a little bit more automated. We've got a small team and every time a new version is released, we have to go back and relearn the commands and how to verify that things were done correctly. That's the one pain point for me: It takes quite a bit of hand-holding, in terms of system administration from our server and infrastructure teams.

The training for configuring new users or operators is confusing because the UI is not user-friendly and has room for improvement.

The technical support team's responsiveness needs improvement.

When it comes to identifying risk in our environment and prioritizing fixes, it is really about the different priorities within the organization. FireMon is not so smart that it can tell what's important to us. It's up to us to figure that out.

We're working on implementing FireMon with our ticketing system service now. Having that would be an improvement. I believe they said that they are working on that for the future. That would help us out a lot. For example, when somebody wants to open a request for a firewall change, we'll go through ServiceNow, and then go through FireMon, make the changes, and make sure everything is recorded, who did it, etc.

The AWS integration is still not mature for us to use. It is just not ready for our use case for AWS connectivity. Therefore, it does not provide us with a single pane of glass for our cloud environments, because we can't manage our cloud environment with the tool.

The map needs improvement in our network. The tool should be able to map out the path of flow from one firewall through our network. However, it does not understand our routing environment, so it cannot do that for us.

We would like it if this solution could provided us with end-to-end change automation for the entire rule lifecycle, but the map feature cannot support our environment, for now.

Policy Planner requirements section is good, but could use some improvement to allow flexibility to enter different types of requests (modifying an existing policy, object or service group, for example) in a structured task format that can be auto-verified.

With fifteen years as a security administrator, I have used few solutions that are as polished as Security Manager. That being said, every solution has room for improvement.

I would like to see the ability to export reports to .xls. This would help me for the following reasons:

• It would allow for greater data manipulation.
• When I run a report, I have the option of saving or exporting that report as .html or .pdf. As someone who catalogs much of their work in .xls, it would be convenient if I were able to export a policy report to .xls.
• This would allow me to manipulate the data better.
• I would no longer need to copy and paste from the .html to .xls and clean up the information.

Some of the core functionality in our environment doesn't seem to work. We will get buggy code releases. They need to work on their Q&A of every code release. Too many bugs pop up between releases, and that's where I would like to see the most improvement.

I basically came on board to do the upgrade, which I've done. So, in the old product, we were able to get things out of the CSV file format and that allows you to then manipulate it, but now it's PDF mainly. Beforehand, we were able to take it into CSV and manipulate it in Excel, but now we can't do that anymore. A revert back on this would be good.

Overall, the product seems pretty good, but the fact that we've taken the CSV out now, that seems to me to be like a step backwards. They should be adding functionality, not taking it away.

One area with room for improvement for me is doing the updates. We have to download it from User Center and then put it unto the machine through FTP, or something like that. I would rather just go to the GUI and hit the Update button, and it goes out and gets the update itself. Because these files are large and sometimes the transfers don't go through, the only way that we're able to do it right now is through FTP. That means we have to have CLI access, which sometimes we don't really want to do. I'd rather just go to the update screen, hit Download the Update, and then be able to reboot it and have it go to all of the data collectors, and transfer that file over there automatically. Right now, it's a process and it takes a lot of time.

It's more complex as opposed to being user friendly. It also depends on your level of knowledge on what to do. Some people may not know to do it, and there are some commands in there. If you don't have support, if you haven't read the entire admin guide, you wouldn't know.

Its reporting can be improved. I am the only one who works a lot with it, and I am having problems in terms of reporting. In the case of Palo Alto, I'm okay with it, but with some of the Cisco devices, such as routers, when I provide the reports to other teams for review, they always say that the hit count is incorrect. So, I was struggling for a long time to work with them. When working with other teams, they have a lot of questions about reporting, such as how it reports, and we are still struggling with that.

During the first year of use we mostly reviewed the results FireMon gave us and used that time to learn about it. We did not go with the recommended changes in-depth, and we did not have many problems. But this year, we tried to go into the details and follow the recommendations. It helped us to remove and clean up a lot of our redundant rules, historically. But in the meantime, especially when we tried to do some advanced rule consolidation or cleanup of historically unused rules, we encountered problems.

The solution does not detect traffic or activities that come and go through our local or site-to-site VPNs. So when we cleaned up some of those rules and encountered issues, we actually had to put them back.

It's not just the VPN, but it also misses some of the rules. Two weeks ago, I cleaned some rules with the FireMon. I ran a report and FireMon suggested that certain tools were not used. When I removed them, while it didn't bring our environment down completely, a lot of our environment started malfunctioning. Our backup system did not work, nor did other things that involve internal and external communication. We are not comfortable with what it did. Since then, I have been busy the whole time just reviewing all those rules and restoring some of them.

FireMon also does not detect the rules with UDP. That's another problem.

Another issue is that our compliance team wants to do some consolidation but that is also a problem because FireMon recommends consolidation based on the ports that we open. We have a grouping system with multiple groups. Under the consolidation grouping, FireMon suggests only based on the port. For example, if we use port 22, we have to share it across the board. It disorganizes the groupings that we have. So the consolidation is not working very well.

Our compliance team also creates reports using FireMon, reports that they send to me. Sometimes I can follow those reports, but most of the time I cannot. In the last two days, I received two huge reports on unused rules and I cannot really use them. At the same time, I'm using my own judgment and my own due diligence. When I doubt a rule, I go back to the firewall and run the history and compare things to help me decide. The problem is that if I always do that, it will take me a lot of time and the solution ends up being 50 percent useful and 50 percent not useful.

We just went from the v7.x to their latest web based v8.x which was a welcome change. One area for 7.x customers that needs improvement is the migration. It is an involved process so get ready to spend some time getting your environment back to the way it was. Another area that could use improvement is the traffic path analysis. FireMon uses learned zone data against interfaces to help determine traffic pathways. The catch here is in v8.x, you now have to specify a source or destination network which may throw off the results sending you to the incorrect firewall. Since we just upgraded last week, there aren't many other items that we can see as improvements as we are just getting familiar with this version.

We've had recurring issues managing FireMon's internal backups. Sometimes, the space allocated for the backup is full, and there is no process where it deletes files that are older than I certain date. It's just waiting for the storage to get full and then it's cleaned up. It isn't something that creates serious issues for us.

I personally have started using it recently, therefore it's hard to pinpoint if anything is lacking. I need more time with the product.

The cost of the solution is pretty expensive. It would be ideal if they could work on their pricing.

We've had issues with backups. We almost lost our database at one point. It would be nice to be able to back up the backup configuration to a network share or some other function. The only way that we know how to do it right now is to do a manual backup. Or the server backs itself up to itself, which is not helpful. If you lose the server, the backup that's stored on the server is also lost. So, it's not that helpful.

One thing that is missing is the ability to export the entire rule base of a firewall. Suppose we were going to be migrating to a different firewall. Not getting rid of FireMon, but moving to a different firewall; either a different vendor or a different model of a firewall. So instead of taking bad stuff, or maybe old stuff out of the current firewall and going to a new firewall and using the exact same configuration, we may want to export that information into an Excel spreadsheet or some other format, so that we could work with that data outside of FireMon. That would be really helpful. I've called FireMon, I've also played around trying to figure out if I could get it to work and I still didn't get it. Nobody knew how to get the info out of FireMon to work on it. Also, potentially the ability to import it back into the system and maybe get some sort of a diff report; a difference of the configuration from the system.

I can mention a ton of areas with room for improvement, but from a high-level standpoint, I just don't think version 8 was ready for prime time, yet. They're still working on it. There are still major swaths of the tool that need attention. To get into the details, I would have to engage my engineers.

So far, we're not too much into the product yet. However, we're not really liking the web interface. We enjoy the so-called fat client a lot better because it just gives a bit more of the opportunities to work with the software faster, whereas there's been a huge learning curve for us to use the web interface. Then, we also have to learn their query language or define the details that we need.

Unfortunately, we are such a fast-paced environment that we don't have a lot of time to spend with the software to really learn it the way it probably should be learned. We have to kind of go back and reinvent it every single time we have to go look for something in particular. That's the only downside I can mention that we're having with the GUI.

Make writing the reports easier. There's a lot of canned reports and if you want to write a specific report that you're interested in looking at, it's rather hard because I'm not a programmer. I don't know all the programming languages needed to do that. I can look at what reports exist and try to take that and kind of change it to something that I want to see and it doesn't always work. It's not real easy to do.

What's funny is that if I had been asked eight months ago about areas with room for improvement, I would have said the product in general needed to be improved. It wasn't web-based. It was client-based and it was just kind of clunky.

In the last eight months since we upgraded to the web version, there isn't a lot of need for improvement. I feel like it is pretty good. Things have been a lot better for us since we upgraded to the web version. I'm happy with it right now and I don't have any complaints.

I would say the most recent release caused us a lot of trouble as we couldn't get it working for a while, so we weren't getting the reports that we wanted, but it has improved. It's just very, very different. The most recent release level was dramatically different.

Maybe better videos or whatever could be included as to how to work with the updated product.

The review process is an area that needs improvement. We would like to review the rules and be able to make comments.

The advanced features are complex in setting up the rules.

I would like to see level mapping available with other products improved, to allow other products to build the level mapping. It does not have an export in Visio.

We had a few minor issues with it. However, it's worked pretty well for us overall.

• Support of checkpoint clusters: Rule usage is logged for each cluster member but not for the whole cluster. It may lead to wrong conclusions when you clean rules.
• Comments with special characters (French accent) are not supported. So we can't use the report for uncommented rules.

We just updated to the latest version, so I haven't had a chance to play with the enhancements from what we were previously using. What I was looking for in the previous version was better capability of adding change control numbers manually for rule changes that don't allow me to put in a descriptor into the change on the actual device. That will automatically get pulled into FireMon for reporting purposes. Some features don't have a description field that I can populate, and so I need to go back into FireMon later and document those. Even though the field is available as an option in properties, there's no way for me to fill that because of the type of the category of the change. It may not be a security change. It could be just a documentation process that I'm not able to do. That was in a previous version. I haven't validated that in this latest version.

I believe their network maps have a lot of room for improvement. I think they should allow more customization.

So far, we're not too much into the product.

• We don't quite like the web interface.
• We enjoy the so-called Fact Client a lot better because it just gives a bit more of the opportunities to work with the software faster. There's been a huge learning curve for us to use the web interface.
• We have to learn their query language or define the details that we need.
• Unfortunately, we are such a fast-paced environment that we don't have a lot of time to spend with the software to really learn it the way that it probably should be learned. We have to kind of go back and reinvent it every single time we have to go look for something in particular. That's the only downside I can mention that we're having with the GUI.

We monitored multiple firewalls. In the version we used, we had to check the changes made on each firewall individually. We didn’t see a condensed list of changes across our environment.

I don't like that it comes with bugs, constant issues, and limited functionality. I would like to have enhanced change management reporting support for UTM features in the next release.

A phone app would be nice. This is the reason why it is not perfect yet.

When it comes to real-time compliance management, something that is missing is alerting on certain, predefined controls. It would be good to have a predefined set of controls which, if not complied with in a newly set up rule, would create an alert for us. That is something that is missing, out-of-the-box. We have tried to work around it by setting up email notifications, but it would be nice if it came with the product. That would really turn it into real-time monitoring for us. 

The workaround works for us, and the out-of-the-box setup is also good, but it expects you to be constantly watching and monitoring the solution itself. That's a bit hard when you have more than one solution to work on. You cannot just watch one and keep an eye on it for something that's non-compliant. Having an alert would be much easier for us. Still, it's a good tool for that kind of monitoring, for us.

I would have preferred fewer updates, as there were quite a few updates made every now and then. Secondly, the Risk Management Module didn’t work well until you have the all of the subnets mapped. This can be improved.

Although there is nothing 'wrong' in FireMon's support for other vendors, with the advent of SDN, NGFW, etc., I think FireMon will have to cover more layer 3 devices from different vendors. Again, their current database covers almost all of the major vendors: Cisco, Juniper, Fortinet, etc. However, there is always room for growth in this particular area.

It’s been a constant need not only to analyze firewall rules and configurations but also implement them, for which FireMon has no support. Also some of the firewall analysis involve weak password policy, FireMon could implement a way to send firewall hashes, when they exist, to third party cracking softwares.

FireMon could be easier to use and flexibility regarding reporting could be improved. 

Needs more functional basic workflow for the Policy Planner for those who do not need a fully customized workflow.

I am desperately looking forward to seeing FireMon considered as a good backup solution for network security devices, which can store up to the last 10 incremental backups. This way, the business can grow with multiple solutions to customer.

They should add SMB firewall support and not only the big players.

The reporting needs some improvement to ensure that we are provided with consistent data accross each firewall device on the network.

Continuous firewall policy improvement should available out-of-the-box for firewall operation. We are also looking for more integration with SIEM and other tools.