Cisco Firepower NGFW Firewall alternatives and competitors

Palo Alto VM-Series is something we recommend as a firewall solution in certain situations for clients with particular requirements who have the budget leeway.  

The Palo Alto VM-Series is nice because I can move the firewalls easily. For instance, we once went from one cloud provider to another. The nice thing about that situation was that I could just move the VMs almost with a click of a button. It was really convenient and easy and an option that every firewall will not give you.  

We would really like to see Palo Alto put an effort into making a real Secure Access Service Edge (SASE). Especially right now where we are seeing companies where everybody is working from home, that becomes an important feature. Before COVID, employees were all sitting in the office at the location and the requirements for firewalls were a different thing.  

$180 billion a year is made on defense contracts. Defense contracts did not stop because of COVID. They just kept going. It is a situation where it seems that no one cared that there was COVID they just had to fulfill the contracts. When people claimed they had to work from home because it was safer for them, they ended up having to prove that they could work from home safely. That became a very interesting situation. Especially when you lack a key element, like the Secure Access Services.  

Palo Alto implemented SASE with Prisma. In my opinion, they made a halfhearted attempt to put in DLP (Data Loss Prevention), those things need to be fixed.  

I have been using Palo Alto VM-Series for probably around two to three years.  

I think the stability of Palo Alto is good — leaning towards very good.  

Palo Alto does a good job on the scalability. In my opinion, it has excellent scalability.  

My experience with Palo Alto is that it is really bad when it comes to technical support. When we have a situation where we have to call them, we should be able to call them up, say, "I have a problem," and they should ask a series of questions to determine the severity and the nature of the problem. If you start with the question "Is the network down?" you are at least approaching prioritizing the call. If it is not down, they should be asking questions to determine how important the issue is. They need to know if it is high, medium, or low priority. Then we can get a callback from the appropriate technician.  

Do you want to know who does the vetting of priority really, well? Cisco. Cisco wins hands down when it comes to support. I do not understand that, for whatever reason, Palo Alto feels that they do not have a need to answer questions, or they just do not want to.  

It is not only that the support does not seem dedicated to resolving issues efficiently. I am a consultant, so I have a lot of clients. When I call up and talk to Palo Alto and ask something  like, "What is the client's password?" That is a general question. Or it might be something even less sensitive like "Can you send me instructions on how to configure [XYZ — whatever that XYZ is]?"  Their response will be something like, "Well, we need your customer number." They could just look it up because they know who I am. Then if I do not know my client's number, I have got to go back to the client and ask them. It is just terribly inefficient. Then depending on the customer number, I might get redirected to talk to Danny over there because I can not talk to Lisa or Ed over here.  

The tedium in the steps to get a simple answer just make it too complicated. When the question is as easy as: "Is the sky sunny in San Diego today?" they should not be worried about your customer representative, your customer number, or a whole bunch of information that they really do not use anyway. They know me, who I am, and the companies I deal with. I have been representing them for seven or eight years. I have a firewall right here, a PA-500. I got it about 11 years ago. They could easily be a lot more efficient.  

I have clients whose architecture is configured in a lot of different ways and combinations. I use a lot of different products and make recommendations based on specific situations. For example:  

• I have one client that actually uses multiple VM-series and then at each one of their physical sites that have the K2-series — or the physical counterpart of the VM-series.  
• I have other clients that use Fortinet AlarmNet. As a matter of fact, almost all my healthcare providers use Fortinet products.  
• I have another customer that used to be on F5s and they had had some issues so switched to Fortinet.  
• I have a couple of holdouts out there that are still using the old Cisco firewalls who refuse to change.  
• I have a new client that is using a Nokia firewall which is a somewhat unique choice.  

I have a customer that used to be on F5s and they had had some issues. The result of the issue was that they came to me and we did an evaluation of what they really needed. They came in and they said, "We need you to do an evaluation and when you are done with the evaluation, you need to tell us that we need Palo Alto firewalls." I said that was great and I sat down and got to work building the side-by-side comparison of the four firewalls that they wanted to look at. When I was done, just like they wanted the Palo Alto firewall was right there as the first one on the list. They selected the Fortinet firewall instead.  

Nokia is specifically designed to address the LTE (Long Term Evolution, wireless data transmission) threats with faster networks and such. So it is probably not considered to be a mainstream firewall. The client who uses Nokia is a service provider using it on a cellular network. They are a utility and they are using Nokia on a cellular network to protect all their cellular systems and their automated cellular operations. The old Nokia firewalls — the one on frames — was called NetGuard. This client originally had the Palo Alto K-series and they switched over to the Nokia solution. That is my brand new Nokia account. They were not happy with the K-series and I am not sure why.  

The thing about Cisco is nobody is ever going to fire you for buying a Cisco product. It is like the old IBM adage. They just say that it is a Cisco product and that automatically makes it good. What they do not seem to acknowledge is that just because their solution is a Cisco product does not necessarily make it the right solution for them. It is really difficult to tell a customer that they are wrong. I do not want to say that it is difficult to tell them in a polite way — because I am always polite with my customers and I am always pretty straightforward with them. But I have to tell them in a way that is convincing. Sometimes it can be hard to change their mind or it might just be impossible.  

When I refer to Cisco, I mean real Cisco firewalls, not Meraki. Meraki is the biggest problem I think that I deal with. I do not have the network folks manage the Meraki firewalls differently than they manage their physical firewalls. I do not want there to be a difference, or there should be as little difference as possible in how the firewalls are handled. They do have some inherent differences. I try not to let them do stuff on the virtual firewalls that they can not do in the physical firewalls. The reason for that is because in defense-related installations it matters. Anytime you are dealing with defense, the closer I can get to maintaining one configuration, the better off I am. Unless something unique pops up in Panorama, I will not differentiate the setups.  

I say that there are differences because there is a little bit of configuration that inherently has to be different when you are talking about physical and virtual firewalls, but not much. I can sanitize the virtual machine and show the cloud provider that since I was going into a .gov environment or a .gov cloud, that it met all the requirements as stated in the Defense Federal Acquisition Regulation Supplement. That is huge for our situation. Of course with a cloud provider, you are not going to have a physical firewall. Had we had a physical firewall, that becomes a bit of a chore because you have got to download the configuration file, then you have got to sanitize the configuration. Things like that become a bit of a burden. Having a VM-Series for that purpose makes it much easier.  

I did not mention Sophos in the list. Sophos does a semi-decent job with that too, by the way. The only problem with Sophos is that they are not enterprise-ready, no matter what they say. I have deployed Sophos in enterprises before, and the old Sophos models did very well. The new ones do very poorly. The SG-Series — Sierra Golf — they are rock solid. As long as we keep going with them, our customers love it. It works. I have one client with 15,000 seats. They are running 11 or 12 of them and they have nothing but great things to say about the product. The second you go to the X-Series, they are not up to the task.  

Setting up Palo Alto is relatively quick. But I also have an absolute rockstar on our team for when it comes to Palo Alto installations. When he is setting it up, he knows what he is doing. The only thing he had to really learn was the difference between the VM-Series and the PA-Series.  

I lay out the architecture and I tell people doing the installations exactly what has to be there. I sit down and create the rule sets. Early on, the person actually doing the fingers-on-the-keyboard complained a little saying that the setup was a little bit more complicated than it should have been. I agree, generally speaking. I generally feel that Palo Alto is more complicated than it needs to be and they could make an effort to make the installations easier.  

But, installing Palo Alto is not as bad as installing Cisco. Cisco is either a language that you speak or a language that you do not. I mean, I can sit down and plot the firewall and get the firewall together about 45 minutes with a good set of rules and everything. But that is me and it is because I have experience doing it. Somebody who is not very well-versed in Cisco will take two or three days to do the same thing. It is just absolutely horrid. It is like speaking English. It is a horrid language.  

I do not have to do budgets and I am thankful for that. I am just the guy in the chain who tells you what license you are going to need if you choose to go with Palo Alto VM-Series. How they negotiate the license and such is not my department. That is because I do not resell.  

I know what the costs might be and I know it is expensive in comparison to other solutions. I get my licenses from Palo Alto for free because they like me. I have proven to be good to them and good for them. When they have customers that are going to kick them out, I can go in and save the account.  

I will tell you, they do practice something close to price gouging with their pricing model, just like Cisco does. When I can go out and I can get an F5 for less than half of what I pay for Palo Alto, that is a pretty big price jump. An F5 is really a well-regarded firewall. When I can get a firewall that does twice what a Palo Alto does for less than half, that tells me something.  

Sophos decided that they were going to play with the big boys. So what they did is they went in and jacked up all their prices and all their customers are going to start running away now. The model is such that it is actually cheaper to buy a new firewall with a three-year license than it is to renew the Sophos license of the same size firewall for an older product. It sorta does not make sense.  

I make recommendations for clients so I have to be familiar with the firewalls that I work with. In essence, I evaluate them all the time.  

I work from home and I have two Cisco firewalls. I have a Fortinet. I have the Palo Alto 500 and I have a Palo Alto 5201. I have a Sophos. My F5 is out on loan. I usually have about eight or nine firewalls on hand. I never go to a client without firing up a firewall that I am going to recommend, testing it, and getting my fingers dirty again to make sure I have it fresh in my mind. I know my firewalls.  

The VM-Series are nice because you can push them into the cloud. The other nice thing is whether you are running a VM-Series or the PA-Series, we can manage it with one console. Not without hiccups, but it works really well. Not only that, we can push other systems out there. For instance, for VMware, we are pushing Prisma out to them. VMware and the Palo Alto VM-Series do really well with Prisma. The issue I have with it is — and this is where Palo Alto and I are going to disagree — they are not as good at SASE (Secure Access Service Edge). I do not care what Palo Alto says. They do a poor job of it and other products do it better.  

Palo Alto claims it is SASE capable, but even Gartner says that it is not. Gartner usually has the opinion that favors those who pay the most, and Palo Alto pays them well. So when Gartner even questions their Secure Access Service Edge, it is an issue. That is one of those places where you want the leader in the field.  

From my hands-on experience, Fortinet's secure access service edge just takes SASE hands down.  

My first lesson when it comes to advice is a rule that I follow. When a new version comes out, we wait a month. If in that month we are not seeing any major complaints or issues with the Palo Alto firewall customer base, then we consider it safe. The client base is usually a pretty good barometer for announcing to the world that Palo Alto upgrades are not ready. When that happens, making the upgrade goes off our list until we hear better news. If we do not see any of those bad experiences, then we do the upgrade. That is the way we treat major revisions. It usually takes about a month, or a month-and-a-half before we commit. Minor revisions, we apply within two weeks.  

I am of the opinion right now that there are some features missing on Palo Alto that may or may not be important to particular organizations. What they have is what you have to look at. Sit down and be sure it is the right solution for what you need to do. I mean, if the organization is a PCI (Payment Card Industry) type service — in other words, they need to follow PCI regulations — Palo Alto works great. It is solid, and you do not have remote users. If you are a Department of Defense type organization, then there are some really strong arguments to look elsewhere. That is one of the few times where Cisco is kind of strong choice and I could make an argument for using them as a solution. That is really bad for me to say because I do not like Cisco firewalls.  

On a scale from one to ten (where one is the worst and ten is the best), I would rate the Palo Alto Networks VM-series as an eight-out-of-ten.  

We're slowly migrating our on-premises solutions to the cloud. We implemented the next largest size VM for the PA-7050s because we're using 7050s on-premises, due to the bandwidth requirement of 100 GBS.

After changing our firewalls to 7050s last year and this year, both our internal firewalls and our border firewalls are 7050s.

Having embedded machine learning in the core of the firewall to provide inline real-time attack prevention is something that will greatly enhance our abilities and some of the things that we're doing. We deal with it daily now, versus a time when an incident only occurred every so often. In fact, we see incidents all the time, which include things like phishing attacks. Having some of the functionality inside the firewall  

I would rate Palo Alto's machine learning capability, which secures our network against rapidly evolving threats, pretty high. We own a product that I want to get rid of by Cisco, called Stealthwatch. It generates alerts and it's really built for East-West traffic. Of the alerts that we get, 99.9% of them are already blocked by the firewall. I'm not really worried about my North-South traffic because Palo Alto is there. For what they have in the box and the different subscription models, I'm not worried because Palo Alto does such an excellent job of catching stuff.

The biggest improvement to our organization since implementing Palo Alto is that there are a lot of things I no longer have to worry about. There are a lot of things that I used to do, that I don't have to do anymore. For example, I don't have to worry about putting up a honeypot. It's superfluous now because I've got default deny and there is no sense in opening up the border to allow people to come onto my network just to go to the honeypot.

The basic IDS/IPS is taken care of, so I don't need to purchase a product like FireEye. I'm not worried about my core, critical systems.

This next-gen firewall platform has definitely helped us to eliminate security holes. Comparing it to Cisco, which is port-based, a port can be spoofed. This is something that we see every day. When going from a port-based paradigm to an application-based paradigm, there is no comparison. It is more granular, which allows me to be more specific about, for example, port 80 traffic. Port 80 has any number of applications that it can be but if I specify applications, I can pick up all of the port 80 traffic. This means that I can make sure that they cannot spoof an SSH connection as a port 80 connection.

As a growing shop, we have been trying to integrate and get something that we can use as a single pane of glass, and we're getting there. Palo Alto has helped a lot. For example, the new feature for us is the data lake, which allows us to send logs anywhere. This is something that we couldn't do before, so this solution has enabled us to do a little bit more and get rid of some tools.

I don't feel that there is much of a trade-off between security and network performance. Our layer-two network is very robust and I build around them. The architecture is based on what our networking can do, capacity-wise. We haven't had to adjust anything, even when we were running the smaller Palo Alto units, to make things function.

Wildfire has been a very good feature. It allowed us to get rid of our honeypot machines, as well as our IDS/IPS solution. When we put it on the border, it was blocking everything that we were getting ahead of time, and we weren't getting any hits. This includes URL filtering, spam prevention, and anti-virus.

We are using a data lake for our log storage. Because our Splunk license is only so large, we couldn't do a lot of logging. Palo Alto does not create small logs, like a Cisco box. In fact, with Palo Alto, you can't capture all of your logs.

From a layer three network perspective, Palo Alto is a workhorse that gives us the best value.

This solution provides a unified platform that natively integrates all security capabilities, which is 100% important to us. This is a great feature.

The user interface is beautiful. They've done their homework on UI design. There are small little tweaks but that's really a preference more than functionality.

One of the downsides of logging with Palo Alto is that we do not capture the beginning of a session. It only captures at the end of the session. This means that if we're trying to mitigate something, such as an incident that happened, we can't say definitively that it happened at a particular time. The reason is that Palo Alto keeps track of every session that happens and if it were set up to do that, we would overload the firewall and overload the logging of anything because we do terabytes worth of data every day.

Having a single pane of glass, where we can see all of the stuff that we have to be able to react to, would be very helpful. We're a small shop but we have to cover the entire security spectrum. It makes it hard because we have to wear many hats. A single pane of glass where we can put alerts and other information would make our life a lot easier. As a small EDU, we just don't have the resources that the private companies have, so we have to try to find the best bang for the buck.

From a documentation standpoint, there is room for improvement. Even Palo Alto says that their documentation is terrible. It may be true for any company, where you're going to find documentation that is outdated or has not been kept up to date, but that's my main complaint.

I have been using Palo Alto Networks NG Firewalls for between 10 and 15 years.

The stability is fire and forget. You don't have to worry about it. I've had to babysit Cisco devices in the past but I've never had to do the same with Palo Alto.

I've always had really good assets over the years and in all, they have changed perhaps two or three of them. Overall, they've been wonderful.

The scalability is wonderful. In the last iteration that I did, I folded 12 different firewalls into one box, across campus, without any problems with network degradation.

Without our two boxes, we have 16 firewalls set up. There are two of us responsible for maintaining the system, and our job titles are cybersecurity network engineers. 

The way the interfaces are set up makes it really easy to use. Also, the different routing protocols that you can use within the box make life easy when it comes to setting them up. 

The product covers the entire university. We use it at the edge for one of the departments, and it acts as their edge firewall. They pay for their solution and we maintain it for them.

We have deployments in other campuses, as well.

As we segment the network, depending on the zoning, we will be adding new interfaces to do certain things, such as setting up DMZs.

The support has been wonderful. I have not had any bad support that I can think of over the years. They've always been there.

Prior to Palo Alto, we used a combination of solutions. This included honeypot machines, and products for IPS/IDS.

We used to be a Cisco shop and I'm glad that we are no longer one. I've been trying to get rid of Cisco for years. The problem with them is that it's unwieldy. It's an old-school way of doing things. For example, everything is port-based. They tried to get into the next-gen firewall space, but the way they grow is that they buy other companies and try to combine technologies to make them work. That doesn't work.

One thing that I've never liked about Cisco, and still don't like, is that if I did an OS upgrade, I was guaranteed that I would be there for at least three to five hours. This was for a simple OS upgrade. Palo Alto has made my life a lot easier from that perspective, which is something that I really appreciate.

Outside of the problem with the OS upgrade, security was becoming more prevalent at the time because of hackers. Cisco was just port-based, and we wanted to move to something that was mobile and more granular. We wanted something that would give us better security and Cisco just didn't have it. 

We don't use the DNS security capability with Palo Alto because we use Cisco Umbrella for that, and it works great.

The initial setup is very easy. I can do it in my sleep. The process will take between 15 and 20 minutes for a new deployment. If it's an existing system that you're moving stuff over from, it depends on whether it's Palo to Palo or from something else to Palo. It can take between two and three hours, depending on how many rules there are, and the other things that you have to set up. Once you're up and running, it takes no time to debug it.

Comparing the initial setup to a Cisco device, Palo Alto is much easier. With Cisco, you can't do a simple reset to factory default settings without breaking it. The time I did this, it took me two weeks to finally get it up and running, and I had to call the Cisco SEs to come in and fix it. That's how bad it was. Setting up Cisco is a nightmare.

In comparison, setting up a Palo Alto is child's play. It's like ABCs versus a university course when it comes to getting something set up in Cisco. We have run into problems with Palo Alto in the past but for the most part, it's an easy process.

When we first implemented Palo Alto, we hired a consultant, ProSys, to assist us. They know our network. They've been with us for years and they've got some Palo Alto experts. The reason we asked for their help is that we didn't know anything about Palo Alto until after we took the courses.

One of the problems at the university, in general, is that we don't do a lot of these processes every day. This makes it hard for most universities to be able to do a lot of these more complex setups on their own without getting outside help. The people who are in big businesses that deploy these things on a daily basis get to see this stuff all the time. Universities don't, so we normally have to rely on outside help.

Overall, our experience with ProSys was good. We like working with them.

Palo Alto is not a cheap solution but it is competitive when it comes to subscriptions.

The hardware is something that you can buy all day long, regardless of the vendor. It's when you start adding in all of the subscriptions that it is either going to make or break the budget. All things considered, Palo Alto is comparable.

There are several extra features available and what you use depends on what you want to do with the firewall, and how it's going to be deployed. AV is an option, the Threat Prevention app is extra, along with URL filtering, and WildFire. You won't have all of the options on all of the servers. For example, the internal servers won't be doing any web surfing, so the requirements are a little bit different.

I'm more worried about my building to building, East-West traffic because I can't afford to put a Palo Alto in every building. Instead, I put a Palo Alto in front of me to deal with the North-South traffic.

We knew about Palo Alto and that's what we wanted, so we did not evaluate other vendors or products.

I've worked with my SE on this with at least four or five other schools that did not use Palo's, but since turned to use them. I speak with my SE often, and I also speak with my colleagues at other schools about my experiences. I generally explain what my experience with Palo Alto is compared to what I've had with other firewalls.

I don't want to become a Palo Alto-centric shop. We can use certain cloud features that they have, such as SaaS products. However, I choose not to, so that we can have a little bit more flexibility in what we do.

When we were a pure Cisco shop, we saw the problems with doing that. Palo Alto does a really good job at everything they do but, I just want to make sure that from my university's perspective, we don't get stuck. If all of a sudden, somebody else comes out with another product, we don't want to be stuck with a specific vendor, unless they are definitely the best solution.

We use other products in addition to Palo Alto to help along the way. For example, we use Corelight from Bro Zeek, Terracotta, and other things that I can stream together and send to our SOC to look at. We also have XDR, although it's not a fully functional one because we don't have the endpoint component. That is what is killing a lot of EDUs because we just don't have the budget or the money to be able to go out and buy all of the products that help us to function the way we need to.

In the NSS Labs Test Report from July 2019 about Palo Alto NGFW, 100% of the evasions were blocked. For a C-level person, that's great news. They read those types of things. As a technical person, it's important to me because it makes my life easy.

Palo Alto sells a next-generation firewall called the PA-400 series, and depending on what a company's bandwidth needs are, it would be a good choice. For example, if they're not doing anywhere close to a gig worth of traffic, such as in a small office, home office, or small business, then it would be a good solution. It also depends on what the business does. If there isn't much traffic then a PA-400 would be fine.

If a colleague of mine at another company were to say that they are just looking for the cheapest and fastest firewall, based on my experience with Palo Alto, I would tell them that they get what they pay for. Palo Alto is not cheap but at the same time, their product is not really comparable with others. It's like comparing apples to oranges.

If you consider Fortinet, for example, they call themselves a next-generation firewall but they really aren't. They are what you call a GPO, which is related to policies. It is important that you look at what other people do and how they do it, but for the most part, there's not anybody out there doing what Palo Alto is. 

Another one is Cisco. They do the same thing that Palo Alto does, although it takes three Cisco boxes to do what a single Palo Alto box does.

I would rate this solution a ten out of ten.

I support multiple clients within the UK, the EMEA region, the US, and now in Asia Pacific as well. I specialize in Check Point firewalls. I design and secure their data centers, their on-premises solutions, or their businesses security.

The firewalls are mostly on-premise because most of our clients are financial organizations and they have strict compliance requirements. They feel more secure and have more control when things are on-premise in the data center. However, there are use cases where I have helped them to deploy Check Point solutions in the cloud: AWS, Azure, and in Google as well. But cloud deployments are very much in the early stages for these clients, on a development or testing basis. Most of the production workloads are still on-premise in data centers.

Most of my customers are still using R77.30, and they are on track to upgrade from that to R80, which is the current proposed version by Check Point.

One of our customers has just recently been attacked by malware and internal DoS attacks, and they have a multi-vendor, multi-layer firewall approach. The internal firewalls are Check Point. The great thing about Check Point is that because of its central architecture, you can very quickly pinpoint where the attacks are coming from. It gives you comprehensive reporting when the attacks start and when they've stopped, so you can see the complete, end-to-end picture: where the point of attack is, at what time, and what host. They can track all of that.

However, in parallel, that customer is using other firewalls which have no visibility. One of the main advantages of having Check Point firewall is definitely that it gives you absolute in-depth visibility.

Among the valuable features are antivirus, URL inspection, and anti-malware protection. These are all advanced features.

One of the great advantages of having Check Point as a firewall is that all of these are software blades, so you can buy a license or subscription and enable them and get the security up and running. With other firewalls, it's a completely different agenda, meaning some of them require hardware modules, and some of them have a complex way of adding the licensing, etc. Check Point definitely has a great architecture, where you can just enable the software blades and deploy a secure service. Overall, it provides ease of deployment and ease of use.

The area it needs improvement is the SandBlast Agent. It receives a file, or if it detects a Zero-day attack, it takes the file and analyzes it, either on-premise or in the Check Point Cloud, and then it reports back whether the file is secure or non-secure, or is unknown. That particular area definitely needs a bit more improvement, because there is a delay. That's one of the main complaints for most of our customers. Or if it is quick, then it's very complex. For example, if they have received a file which is "unknown" or has Zero-day attack malware, sometimes it doesn't get analyzed properly or it's locked into the cloud. So there are various small issues with the product that need possible improvement.

The SandBlast product on its own is a very good concept, and it works absolutely brilliantly. However, when you integrate it with existing firewalls, it just doesn't play very well.

The cloud solution is quite straightforward because it seems the SandBlast solution was designed, initially, for cloud deployments, where you've got multiple clouds or multiple vendors, and you are receiving files from different points. And on the cloud edge, for example in AWS, if you have Check Point sitting there, it works very well if you're running a virtual firewall. However, if it's on-premise and it's a dedicated appliance, then the performance is slightly different and the way it works is very different. So where it needs improvement is where it's an appliance-based solution rather than a software or cloud-based solution.

If I am using SandBlast on a virtual appliance — for example, I've got Check Point virtual appliances in AWS, and Azure as well, for a customer — those virtual appliances work absolutely fine as a service, as does SandBlast as a service. However, if it's an appliance, if it's a dedicated firewall on-premise in a data center and you add SandBlast as a software service, the integration is not that straightforward, so the experience is very different. 

It seems like they were possibly built by different teams, independent of each other.

I've been using Check Point firewalls for about 16 years. I am the main network or security lead and I have four other engineers who report to me. They also do design and deployment.

I work with approximately 40 companies that utilize Check Point.

Check Point firewalls are very stable. One good thing about Check Point is that they do rigorous testing internally before releasing updates, which is something I have not found with any other firewall products. With most of the other firewall products, when they release something, it's like the customer becomes the guinea pig for that particular version, whether a minor or a major update. However, with Check Point, you can see all the white papers and what ways they have tested a minor or major upgrade of the software version, and what the performance was like. What are their known issues and is somebody working on them or not?

So the software releases are very stable and you have visibility into how they operate and what the known issues are, so you know whether you should go ahead with them or not. And in case there is a problem, the support is excellent. You can reach out to Check Point and say, "Look, I've done the software upgrade and I'm experiencing these problems. How can I deal with them?" They are there to help you out.

There are times when we have problems in terms of software or hardware defects. We have sustained downtime, but most of the architecture I design is resilient, so if one device is down, the other one is working fine. Then in the background, I or my support team will deal with Check Point directly, to get a replacement. They're definitely quick to respond and very efficient. 

In the past, we had a lot of problems with licensing, specifically, but Check Point has redone the whole way they do licensing. It's very quick now, and very efficient.

Check Point firewalls are extremely scalable. Recently, I deployed Check Point in an AWS cloud solution for one of my clients, and it's been absolutely excellent in handling growth. They've grown from 10,000 users to a million users. The way Check Point has advertised the product, it is supposed to be highly scalable, which means it grows as your demand grows, and that has been the case. 

Recently we have set up a test case where we are moving over management servers from on-premise to a Check Point-provided Infinity cloud solution. We are still at the testing phase but, overall, it's been a great experience so far.

The teams we deal with within Check Point are extremely knowledgeable. They know how to understand the background of the problem, and they're very good about articulating how we deal with the issue, whether it's a minor software upgrade issue or it's a major failure of the hardware itself. They know where to look for the right stuff. The key point is they're very knowledgeable and very technical. And if somebody doesn't have the technical capability, they will definitely help you out to make sure you get to the bottom of the problem.

In the past, most of the customers I've worked with have used different firewall vendors, such as Cisco, Palo Alto, and Juniper.

I've recently seen deployments where customers have tried to move from Cisco ASA to Cisco Firepower and the deployment has gone horribly wrong because the product has not been tested by Cisco very well and is not a mature product. I've gone in and reviewed their business requirements and technical requirements and, based on that, I've recommended Check Point and done the design and deployment. They've absolutely been happy with the solution, how secure and how capable it is.

We use Check Point across multiple types of customers, such as financials, retail, and various other public and private sector organizations. I review their security architecture, which is firewall specific and, based on that, I have recommended Check Point. In most cases, I've managed to convince them to go ahead with Check Point firewalls as a preferred secure firewall solution.

The main reason is that Check Point is far ahead in the game. They're definitely the market leader. They are visionaries when it comes to security. Another reason is that a lot of firewall architecture starts from the firewall itself, which is the local firewall. It can easily be hacked and manipulated. However, the Check Point architecture, out-of-the-box, is very secure. They have a central Management Server and all of the firewalls are managed through that one central point. So in case somebody breaks into your firewall, the firewall is encrypted; they will delete the database. The architecture is secure by default. The good thing is that other firewall vendors have realized this and they've started to copy the same system that Check Point has used for the past 20 years now.

When working with the Check Point team on deployment, they're really helpful and very talented people. When you speak to other firewall vendors, they just think about the firewall from their point of view. The good thing about Check Point engineers, or technical staff, or even management staff, is that they understand what the requirements of business are and how they can improve or align the proposed solution. Overall, Check Point staff are very knowledgeable, they understand different industries, and they understand the product very well. That's definitely a competitive edge compared to other firewalls.

Once the design is done, for something simple the deployment can take half a day, whereas for a complex deployment in a data center it can take about five days.

Our implementation plan is divided into different phases. Phase One might be the physical cabling of the firewall device itself. Phase Two would be the logical setup, which means defining the interfaces and the virtual setup of the firewall itself. The final phase would be to bring it online in parallel with production, in a non-prod service, and test it to ensure it works as per the design.

A customer I'm working with right now was running with Check Point and they wanted to move to Fortinet firewalls. However, when I worked with them on the design to upgrade the existing Check Point firewalls, what we worked out was that even though the Fortinet might have seemed like a cheaper option, it didn't have the security capabilities that Check Point is offering. On that basis, the customer signed off on a project for upgrading their existing firewalls, on-premise and cloud, from R77.30 to R80.10.

It can be expensive, but it's value for money. What you pay for is what you get. You can go down in price and buy some cheap firewalls, but you're not going to get great support and you're not going to get the level of protection you need. With Check Point you get all of that.

With Juniper, one of the biggest downsides is support. The support portal is slow and I won't say the staff is competent in terms of understanding. They're very disconnected internally. What I mean is that the team working on the software development of the firewall has no interface with the support teams that are handling day-to-day TAC cases. They definitely struggle when it comes to understanding challenges, problems, and incidents with the firewalls.

In the past, Juniper firewalls were good, but recently the security offering has just not been there. They don't have anything like SandBlast from Check Point. They don't have up-to-date Zero-day attacks control. They're still running a very old architecture. They can do things like antivirus and URL proxy, but those are very simple features. They have none of the advanced feature set that Check Point has.

Palo Alto is very competitive with Check Point when it comes to security. However, one of the challenges with Palo Alto is that, overall, the solution can be extremely complex and expensive. That is one thing I've heard from customers again and again. Either they have existing Palo Altos or they plan to go to Palo Alto, but when they do a comparison with Check Point, what they find is that the overall value with Check Point is much greater than with Palo Alto firewalls.

If you're looking to implement Check Point as a security solution, definitely do your homework. Do some research, not just in terms of firewalls, but overall security architecture. Which ones are the leaders in the field? Which ones are there to deliver what they promise? And overall, how does the architecture work? Is it secure or not? And does it come from a team that understands how to support the solution itself? Are they consistent? Look at their track record for the past 10 or 15 years, or are they a new player? If they are, you don't know whether they're going to stay in the game or not. A good thing about Check Point is that its core product is security. They've been doing it day in and day out. You know they're there to stay in the game. You can trust them.

Check Point is a proven solution. A lot of customers and clients already rely on it. And for the Next Generation Firewalls, they're coming up with new features as security threats become known.

If somebody wants a secure and stable environment, Check Point is definitely the leader to go to; definitely the number-one choice. It's not only what it says on the box. In reality, I've worked with hundreds of banks and they're happy with the product because it works; in practice, it works. That's the main thing.

When we started using Azure Firewall, we learned quickly that it couldn't do much. As I remember, it was essentially a layer 3 or layer 4 firewall that couldn't distinguish recognized applications and things like that. But it was inexpensive compared to the Palo Alto stuff we were looking at, so we wound up staying with the firewall. Mainly it was just inspecting ports between virtual machines.

Azure Firewall definitely needs a broader feature base. It should be able to go all the way up to layer 7 when looking at applications and things like that. It needs to be comparable to what you would get from Cisco, Palo Alto, Checkpoint, or any of those guys. If it's going to be a firewall, it needs to be competitive. From a security standpoint, it's not any better than loading an IP table in a Linux box. In fact, Linux may even be better in that sense

I've been using Azure Firewall for probably about a year.

Azure Firewall wasn't scalable at all, but it did what it's supposed to do.

I honestly don't remember interfacing a lot with Azure support. I think that we were dealing with a third party, maybe. But I've been dealing with AWS for the last year, and it's a totally different experience in a good way. Their support is outstanding.

Setting up Azure Firewall was easy because all you were doing was configuring source, destination, port, and action. However, there was something weird. You have to number your rules set, and depending on your numbering system, that's how you would have to apply the filtering of the logic of the policy. And in that sense, it's a little bit quirky. I don't think that most firewalls work that way. It just reads the policy, and the algorithm is based on it filtering down through the policies until it hits a truth or a match. And then it makes a decision based on that.

Azure's cost-effectiveness is its major advantage. 

Each company will prioritize what it wants to work on. Azure may outperform AWS in some areas, but after working with the two platforms for roughly the same amount of time, I've found AWS friendlier and more sophisticated overall. AWS just seems to be a better platform for me, honestly.

I would rate Azure Firewall one out of 10. I give it the worst rating because security is so important. However, it depends on your security goals. But you have to look at what's out there and what you typically get out of a box. Even for a cheap application for your computer, Azure Firewall just isn't delivering. It doesn't have any personality at all or functionality even. I definitely wouldn't recommend it to anyone, but I would have to go back and visit it because it's been a year now. The features are so limited that it's pretty much a protocol-filtering product. 

Honestly, I think any serious security-minded entity will bypass Azure Firewall and look at some of the images from the third parties. I guess it's suitable for small outfits that aren't serious about security but want some basic protection. By the time I walked away, I  had spent a lot of hours on it, and I spent more time in my job trying to find a solution and pick the right one. I did everything to learn the firewall's feature set. I finally talked with someone at Microsoft who said, "We know what you want and what you're trying to do, but we're just not there yet."

They just told me to stay tuned. I got the impression Azure Firewall is a very immature product that would probably improve over time. But, at that moment, I didn't think it was unready. It's just that products are trying to achieve different things. You can't have all the horses in all places. It's one of those things where I felt like it would have to be some acquisition or complete outsourcing of the security component to somebody specialized in the area who can sell it as a firewall.

Basically, we are using these products for our waste filtering, then application filtering and bandwidth management purpose.

The major benefit is that I can shape my bandwidth, basically. In Bangladesh, we do not have a lot of bandwidth management or bandwidth capacity. We have a limited capacity and we share the many people in this capacity. I can shape my bandwidth using this Sophos file, so everyone gets a minimum level of bandwidth. If the user is higher-end, then getting the lower end and the user has the minimum level or less than 1000 or 500, and they're getting better than that.

Sophos has a feature for user credentials, which means if users are not logging into the capital portal of Sophos, they're not using any internet. We can advertise some products and features using these portals for our university. Basically, I am working at a university, so the university's different features and the different departments are using this portal. If students see this advertisement and then after they log in to the credential in the capital portal and use the internet.

Sophos is good for a mid-level company, not a large-level one. If the user level is very large, Sophos is not capable of handling such a high level of users. It, therefore, needs to improve the devices so that they work in larger organizations and with a large number of users.

When we use the hardware level of the device, the RAM or other storage capacity is fixed. We could not change the memory or other capacity of this device. If we need some improvement in capacity, we get different types of problems. If RAM usage is too high or capacity moves higher, the Sophos device does not work properly.

Sophos has a number of additional features, however, the user graphical interface, the graphical interface when we are using CyberRoam, the user portal, or user interfaces, are so much smarter than Sophos. In Sophos, the user portal is not user-friendly. This needs to change, the UI.

I've worked with the solution for the last four years. 

The solution is stable and reliable. There are no bugs or glitches, and it doesn't crash or freeze. I'd rate the performance at 75%. Some improvements could be made. 

We have 4,000 or 5,000 people that are connected in Sophos.

It is not easily scalable as it has fixed capabilities and that means C2 RAM is fixed. That makes it not easily scalable.

We use the product on a daily basis. 

Sophos' technical support is not good. I have not been getting better support from their technical people. The response time needs to be better.

I am also using the Cisco Firepower model 4110.

The main difference is basically Sophos is not like a Firepower. Sophos we can call by the UTM device management. For security purposes, we are using a Cisco firewall for different types of attacks. For bandwidth management with filtering and other activities, just normal activities, we are using Sophos.

The initial deployment is not complex, however, it's mid-level. You do need some experience. It depends on the device model. If we purchase the higher model, then the price or other investment is also more.

The deployment takes a maximum of one month. We do maintenance on the devices maybe once a year. 

For the deployment process, the partner helped us deploy the devices and three people were working on the deployment.

The initial price is high and we purchased a three-year licensing model. Every three years, after every three years, we need to renew Sophos. Everything is included under the license. 

The pricing is quite low, and we are quite happy with it.

We're a customer and end-user.

We are using the hardware version of the product. It's the latest version. 

I'd rate the solution a seven out of ten.