Check Point CloudGuard Network Security Reviews

It is building the network infrastructure for our cloud environment around it. Primarily, the functionality that we are using it for is the firewall piece in the cloud.

We have three different things going on right now. I think Dome9 is considered a part of the whole CloudGuard thing. We have AWS and Azure environments behind just straight up Check Point Firewalls. We are in the midst of deploying a new network in AWS that fully leverages the whole IaaS that they offer. Primarily, it's the firewall main piece. However, we are transitioning into using the scale-up, scale-down gateways, which are mostly the network security piece of it.

The granularity and visibility that we are able to get into logging and data going into our AWS environment is significantly more than we could get purely out of the native AWS tools. That is big for alerting and incident response.

The Auto Scaling functionality is the most valuable feature. Our cloud environments are growing to the point where we need to be able to expand and contract to the size of the environment at will. They pull you to the cloud. With the static environment that we currently have stood up, it works well. However, it would be more efficient having the Auto Scaling even bigger. We are in the middle of that now, but I can already tell you that will be the most impressive thing that we're doing.

CloudGuard's block rate, malware prevention rate, and exploit resistance rate are tremendous. CloudGuard is functionally equivalent to what we are doing on-prem. It's easy to manage CloudGuard from on-prem and offers the same protection that we're able to give the rest of our environments, which is a big plus for us.

The comprehensiveness of the CloudGuard’s threat prevention security is great, especially once they integrate Dome9 in the whole thing. That really ties the whole thing together, so you can tie your entire cloud environment together into one central location, which is nice. Previously, we had three or four different tools that we were trying to leverage to do the same stuff that we are able to do with CloudGuard.

I might be a little skewed because I have been working with Check Point for so long that a lot of the same logic and language that the rest of Check Point uses becomes intuitive, but I haven't had any issues. Anything we need to get done, we are able to do it relatively easily.

The room for improvement wouldn't necessarily be with CloudGuard as much as it would be with the services supported by Check Point. A lot of the documentation that Check Point has in place is largely because of the nature of the cloud. However, it is frequently outdated and riddled with bad links. It has been kind of hard to rely on the documentation. You end up having to work with support engineers on it. Something is either not there or wrong. Some of it is good, but frequently it's a rabbit hole of trying to figure out the good information from the bad.

We use the solution’s native support for AWS Transit Gateway and are integrating it with the Auto Scaling piece now, which is a big portion of it. One of the issues with using the AWS Transit Gateway functionality is that setting up the ingress firewall can be more of a logging type function, as opposed to doing pure, classic firewall functionality. This is with the design that we are using with the Auto Scaling. However, AWS announced about two weeks ago that they have a new feature coming out that will effectively enable us to start blocking on the Check Point side, and with our previous deployment before, we weren't able to do that. While the Check Point side is fine, the functionality that AWS allowed us to use was more of the issue. But now that changes are occurring on the AWS side, those will enable us to get the full use out of the things that we have.

We have been using it since before it was even called CloudGuard, which has probably been five years now.

The stability is great. There are no real issues with it. Even when half of AWS went down last week at some point, our stuff stayed up. Check Point is actually fine, it's more of just whether or not AWS is going to stay alive.

The scalability is great. That is the big thing. We went from our existing not-that-scalable network to a full scale-up, scale-down. I feel like it's inherently scalable because of that. It gives you as much power or as little power as you need.

Currently, there are about 150 users in our organization. When the new deployment is done, there will be about 700 users. Right now, it is primarily software development. These are the people who are in there now spinning up and down servers, building out environments, etc. It's just going to be that on a larger scale once the new deployments are out there. We need to have the guardrails in place with CloudGuard and Dome9 to ensure that they don't wreck the company, but it's mainly software development and the various roles inside of that, like architecture. There are a hundred different teams in the company that do dev, so they each have their little functions that they would have to do in there.

Right now, the solution is lightly used, given the fact that most of our development is taking place on-prem. However, we are eventually moving everything to the cloud. By virtue of that fact, it will be heavily used for the next two to three years.

Support has been great. They will get you through any issue.

The documentation has been rough. Being able to do it yourself can be hit or miss given the constraints of the documentation.

We deployed our AWS environment in tandem with our CloudGuard deployment. There were individual pieces of AWS that we were using that we've replaced with CloudGuard, but those pieces were more on the Dome9 side than anything, like flow log exports, that we were able to consolidate back into Dome9 and CloudGuard.

The initial setup is generally complex. I have been doing cloud and Check Point stuff for a while. Therefore, when we deployed this stuff, I had a good understanding of how to negotiate both of them. That being said, I can see how a user who doesn't have this level of experience may see it as being difficult. I just have a lot of experience with this stuff and was able to get it stood up relatively easily. But, if you're not in the weeds with Check Point and AWS, then I can definitely see it being complex to set up, especially given the issues with documentation, etc.

The first deployment without Auto Scaling was probably about a month. It was kind of in tandem with building out the cloud environment. Our latest deployment was about two months, but it has been a significantly more complex design that we were doing, so it was sort of expected. It was not a full-time thing that we're doing. We were working on it a little at a time. If a team already had their AWS environment fully designed and operational, then they could have it up in a week. A lot of our challenges have been just tied to the organization and changing what it wanted out of the deployment, which has been more an internal issue for us.

Initially, our implementation strategy was a multicloud deployment. Then, it switched to a single cloud. After that, it shifted to the number of environments that we had to get stood up. So, it has been a bit all over the place internally. We know we have to do it, it was just a question of how many networks did we need to stand up, how many environments, etc. From a managerial leadership perspective, it was just telling us what they want.

Largely because we are a large Check Point shop who used on-prem going into it, most things are identical between the cloud and on-prem deployments. So, the things that we were able to do on-prem, we were then able to easily extend those out to the cloud.

We use Check Point’s Unified Security Management to manage CloudGuard in multiple public clouds and existing on-premises appliances. We had it in place before we had CloudGuard. Therefore, it was an easy transition to integrate that stuff. It wasn't that we had something else in place, then we brought in CloudGuard. We had the Smart Management Suite already set up on the internal end, and we were able to integrate that pretty easily.

99 percent of the time, we are doing the deployment ourselves. Here and there, we will have a one-off, but we do the deployment ourselves.

There are three of us who were involved in the deployment, which are the same people who are doing the maintenance.

The ROI is significant. We definitely would need more people on this team to manage this stuff if we were not using Check Point. The cost of having more security engineers and cloud engineers, in particular, is expensive. It prevents us from having to blow money on people who are just staring at the cloud all day.

The use of Check Point’s Unified Security Management to manage CloudGuard in multiple public clouds and existing on-premises appliances has freed up our security engineers to perform more important tasks. If we were tied down using four or five different tools, that would be a nightmare for us because we are just a small team. There are about three of us managing the cloud environments right now. If not for this solution, we would easily double or triple our team size. The number of different tools needed to manage (without CloudGuard) would be too much for just three of us.

The pricing and licensing have been good. We just had to do a license increase for our portion of it. We had that done within a couple of days. Given the fact that it's purely a software-based license, it ends up being even quicker than doing it for an on-prem firewall.

The only other thing that might come up is if we ever decided to do any managed services type of thing or bring in consultants. Outside of that, their cost is what it is upfront. This is outside of whatever you will end up paying AWS to run the servers. It is all pretty straightforward.

We kind of always knew it was going to be Check Point because of our extensive on-prem deployment. It just seemed easier for us to just stay with them instead of having multiple firewall providers. The only other real option for us at the time was just going with native AWS firewalls, but we would rather keep that managed ourselves with Check Point.

The only thing that we ever looked at or compared CloudGuard to is just native AWS tools and whether it makes more sense to use them than CloudGuard. By and large, we just kind of stuck with CloudGuard for the most part. There are definitely more menus that you can navigate over than AWS. Check Point's tools are good and powerful, but given what our deployment looks like, that just complicates things.

Favorable results of its security effectiveness score from third-party lab tests were very important to us. We didn't evaluate too many other options. Just knowing that it wasn't a piece of garbage was a good indicator upfront that it was worth sticking with Check Point down the road. If you are given more things that you have to look at, then there are more possible threats capable of penetrating an environment. So, if you're able to centralize things as much as possible, then you're on the right foot to catch any issues.

With the integrated nature of the Check Point suite, you can have everything under a single pane of glass, which is huge. You can do a lot of the things that you can do with Check Point if you had four or five different other vendors, but being able to do it all in one place is convenient and cost-effective.

In our decision to go with this solution, it was absolutely important that Check Point has been a leader for many years in industry reviews of network firewalls.

We should have done the Auto Scaling stuff upfront instead of going static. The biggest lesson was that the tools in place let you embrace the good parts of the cloud, which is flexibility and cost savings. The thing that we kind of learned is we just treated it upfront like it was another on-prem device, but you miss out on the whole point of having infrastructure as a service if you're not going to leverage it to its fullest capabilities.

Remember that you are doing this in the cloud, so treat it like a cloud device. Don't suddenly try to extend your on-prem network without leveraging the whole capabilities that CloudGuard gives you to scale your network in and out as needed.

CloudGuard's false positive rate is acceptable and low. You have pretty granular control over everything that you are doing. Even if you're running into false positives, you can easily tweak them and work with CloudGuard to eliminate them.

I would rate it a nine (out of 10). It does everything that we wanted it to. It kind of grows with AWS, where new AWS functionality is now enabling new CloudGuard functionality by virtue of a couple of changes that they have been making. They sort of work hand in hand. The only reason that stops it from being a 10 (out of 10) is just the limitations of AWS end up being the limitations CloudGuard as well. You take the good and the bad of the cloud.

Most security solutions traditionally have been protecting physical assets within an environment, or reliance on an inline hardware appliance. CloudGuard takes the security controls that were previously packaged with physical appliances in mind and extends them to the virtual infrastructure.

It's an add-on capability to an existing virtual infrastructure, such as an AWS, Azure, or even on-premise solutions. It adds a security layer on top of your existing infrastructure with zero latency.

We're hosting it ourselves on our hypervisors, as well as starting to do so in some of our private cloud instances. It's solely managed by us with a pair of consolidated management servers.

This virtual platform is unique in the way that it augments our existing physical controls through a centralized management system. When many organizations, like ours, went from physical servers to virtual servers and desktops, there was a blind spot there. We no longer had visibility into what was happening within our environment, and that extended to the cloud as well where it's difficult, if not impossible, to introduce hardware — firewalls and other security protection. This solution takes what is still required around intrusion detection/prevention, anti-malware, and other threat protection capabilities and extends it to all of our virtual assets, regardless of where they live, in a private or public cloud.

CloudGuard has closed a significant gap that we had in our environment. We were searching for the right solution for many years, to gain visibility into, and protection of, all of our virtual asset servers, desktops, and workloads. There have been other products throughout the years that provided a similar type of technology, but had we purchased and move forward with those, we would have seen a degradation of performance within our environment, as traffic would have to be what's considered "hair-pinning" and going in and out of the virtual environment to another either virtual or physical appliance. We intentionally delayed our purchase of this kind of solution because we were not satisfied with that architecture. We weren't willing sacrifice performance degradation on our network. That's really the big benefit of the CloudGuard, it is able to live within the same virtual instances as the other virtual assets and workloads.

What's most valuable to me is that it's a contiguous solution that aligns well with the components that we've relied on and trusted from a traditional hardware, firewall, and unified threat management system. My engineers and analysts don't have to learn another platform. We have already entrusted our security controls to Check Point for perimeter and physical security, and now we can do so at the virtual layer as well, which is key to us. It really augments their current stack of capabilities. It all aligns well under their umbrella of their Infinity architecture, which we have adopted.

It's meeting our needs at this time. If I could make it better, it would be by making it more standalone. That would be beneficial to us. I say that because our current platform for virtualization is VMware. The issue isn't any fault of Check Point, it's more how the virtualization platform partners allow for that partnership and integration. There has to be close ties and partnerships between the vendors to ensure interoperability and sup-portability. There is only so far that Check Point, or any security vendor technology can go without the partnership and enablement of the virtualization platform vendor as it relies on "Service Insertion" to maintain optimal performance. 

We are frequently in contact with Check Point's Diamond Support, Product Development Managers as well as their sales team, as we look to keep apprised of where the product ius and should be going. Most of our requests have been around our physical assets, the physical UTM devices — Check Point Maestro, as an example — as well as their endpoint systems. There has not been anything at this time where we've said, "We wish CloudGuard did X differently." CloudGuard, in my opinion, having recently talked with them, is continously improving and is incorporating some of their recently acquired capabilities, such as Dome9 cloud compliance. Those are areas I have been evaluating and looking to add to my environment. My preference would be that it be included in my CloudGuard subscription licensing, and not an add-on; But that's the only thing that I could say that would be beneficial to us as an enhancement to the system.

We've been using Check Point CloudGuard IaaS for about three years.

The stability has been great. There has been no concern at all. We have not had any known downtime or issues to speak of.

Scalability was well thought out and designed. I've spoken about this at several Check Point CPX events. Throughout the instances that we have, if a single Check Point CloudGuard instance is overloaded due to event load, it will intelligently redirect that workload to another service on a different host, so that it's not delaying the interrogation of the traffic.

It's being used throughout our environment. We will increase usage only when we augment our cloud offerings.

Users, in this case, are the IT security and networking folks that support it and rely on these controls being effective. They analyze the output of the event interrogation. Right now, I have three resources supporting CloudGuard. I don't have dedicated staff for maintaining the solution. They're shared resources who work on other network and security devices. From an operational standpoint, it's a fraction of an FTE that is required.

Check Point's technical support for this solution, overall, is very good. Check Point has architected this solution well enough that it has similar, if not the same, code base as the physical devices. It doesn't appear to be a big lift and can leverage the same support engineers for CloudGuard as we would have for our physical devices.

We never found a solution we were satisfied with, and which would not affect our overall operational performance.

I was not personally involved in the initial deployment, as I'm the CISO of the organization, but I was closely engaged with my engineers. The CloudGuard portion of our installation and setup was extremely simple, in comparison to the integrated component on the virtualization side of things. Check Point made it extremely easy to deploy and configure, especially because it's done from our consolidated management devices that we're already familiar from our physical unified threat management devices.

The delays in deployment were mostly due to the virtualization side of things. If it was just CloudGuard alone, we probably could have had that done in about six to eight weeks. But there were several starts and stops due to the accompanying VMware component, which has really extended, I hate to say it, over 12 months.

In terms of our implementation strategy, the intent is that every host in our environment that serves up virtual assets and workloads would have an instance of CloudGuard installed on it. And then all respective HTTP/HTTPS traffic would be routed through Check Point for visibility and interrogation, so that if any of its threat controls determined that an asset was rogue or infected due to some malicious insider or outsider, it would automatically quarantine that device. We have tested that and it worked successfully.

We installed it with the help of Check Point-badged engineers. To be honest, we had to ask for a new lead engineer. And once that occurred, the project implementation went very smoothly.

ROI is a very difficult metric in the security space. We've been fortunate that we haven't had an event in which we would say that because of CloudGuard our MTTD and MTTR was low and we quickly identified and stopped a malicious adversary.

However, we are now more confident in our security controls and visibility. CloudGuard plays a significant role in our SOAR (Security Orchestration Automation and Response) initiative. We can now automate the isolation of an infected machine with the help of CloudGuard.  This in itself is the best ROI as it doesn't require manual intervention to detect and respond.

The pricing and licensing of this is much more digestible than that of its hardware equivalent. I've found, in times past, especially on the hardware side of things, that the licensing support and maintenance could be very daunting to understand. If that has scared folks away in the past, CloudGuard is much simpler. 

Licensing is simply by the number of hosts that you are looking to protect within your environment. It makes it much easier to ensure that you are covering your environment.

If you are not already a Check Point customer for the UTM and the SmartEvent, there likely would be an additional cost, beyond the standard CloudGuard licensing, if you wanted the reporting. It's a unique instance where we already had an established infrastructure of Check Point devices on our network, and then we added CloudGuard to it. Had we started with CloudGuard, and only had virtual assets to protect, it is possible that there would be additional cost. I would urge folks to look into what it would cost to add the reporting capabilities and log event management.

We looked at offerings from Cisco (ACI), Illumio and Gigamon. This was about three-and-a-half years ago.

The main differentiator, and the reason we selected Check Point, is how it integrated with our virtualization platforms. It lived there natively. It had the least amount of overhead to interrogate the traffic within our environment. It also aligned well with our consolidated reporting and management solutions that we have come to rely on from our Check Point physical UTM devices.

Intently know and understand the integration points within your environment. It is a great security solution, but understand how integrated it is with, and what level of partnership there is between, Check Point and the virtualization platform that you're looking to add it on top of.

The biggest lesson I have learned is that the Check Point CloudGuard features, although good, are only as good as the accompanying virtual platform and its level of integration. I have to be honest: Overall, this is the ideal solution for us and our organization, but it is slightly more complex. There are newer competitive products that take a different stance, that are agent-based. We did not want — and this is another key distinction — a solution that wasn't agent-based in which we had to deploy a piece of software on each and every virtual endpoint. Having this done at the hypervisor level definitely was the right strategy for us. However, the lesson learned, with this type of solution, is that it is very important to understand the nuances of your virtualization platform and what is required on that side to enable the Check Point CloudGuard.

You're relying heavily on the partnership and the capabilities of that virtualization platform. Going in, understand the degree of that partnership and the respective road maps of each, because the CloudGuard solution is only as good as the capabilities it has with the virtualization platform. That's especially true for large enterprises that want to constantly move workloads around and have their rule set follow in an event where they're having to ensure that systems are always alive and always protected.

We use CloudGuard IaaS for cloud security in AWS, and it serves all kinds of purposes for us. It could be internal segmentation between on-prem or between application VPCs, and it can also help us to provide perimeter security for those parts of the network that require internet access.

Our company has a very dynamic IT landscape, and the demand to go live is very high. That means we have to deliver connectivity in very short time frames, and we can do that using CloudGuard IaaS. Once we have figured out a working template for connectivity, it becomes our standard, and we can run connectivity for new applications within a day or two, and sometimes it might only take hours. In the past this would take a much longer time. We also now have much better control over the sizing of the firewalls, which gives us a lot of flexibility in our planning.

In addition, we use an existing on-premise appliance, which is a multi-domain security server. The use of CloudGuard's Unified Security Management was an easy part of our integration. We didn't need to make a lot of effort to incorporate the new firewalls. We just needed to apply some existing policies to the new firewall. We didn't have to develop something from scratch. We just used our existing infrastructure and existing policies, and it was the easiest part of the deployment. And the use of the Unified Security Management has definitely freed up security engineers to perform more important tasks.

The features of the solution which I have found most valuable are its flexibility and agility. It's a fully scalable solution, from our perspective. We can define scaling groups and, based on the load, it will create new instances. It's truly a product which is oriented toward the cloud mindset, cloud agility, and this is a great feature.

Check Point is a known leader in the area of block rate, so I don't have any complaints about it. It's working as expected. And similarly for malware prevention. When it comes to exploit resistance rate, it's excellent. I haven't seen any Zero-day vulnerabilities found in Check Point products in a very long time, which is not the case with other vendors.

The false positive rate is at an acceptable level. No one would expect a solution to be 100 percent free of false positives. It's obvious that we need to do some manual tuning. But for our specific environment and for our specific traffic, we don't see a lot of false positives.

Overall, the comprehensiveness of the solution's threat prevention security is great. It was changed in our "80." version and I know that Check Point put a lot of effort into threat prevention specifically, as a suite of products. They are trying to make it as simple as it can be. I have been working with Check Point for a long time, and in the past it was much more complicated for an average user, without advanced knowledge. Today it's more and more user-friendly. Check Point itself has started to offer managed services for transformation configuration. So if you don't have enough knowledge to do it yourself, you can rely on Check Point. It's a really great service.

Check Point recently released a feature which recognizes that many companies are going with the MITRE ATT&CK model of incident handling, and it has started to tailor its services to provide incident-related information in that format. It is easier for cyber security defense teams to analyze security incidents, based on the information that Check Point provides. It's great that this vendor looks for feedback from the industry and tries to make the lives of security professionals easier.

I highly rate the security that we are getting from the product, because the security research team is great. We all know that they proactively analyze numerous products available on the IT market, like applications and web platforms, and they find numerous vulnerabilities. And from a reactive point of view, as soon as a vulnerability is discovered, we see a very fast response time from Check Point and the relevant protection is usually released within a day, and sometimes even within a few hours. So the security is great.

Clustering has not been perfect from the very beginning. There weren't too many options for redundancy. It was improved in later versions, but that's something which should be available from the very beginning, because the cloud itself offers you a very redundant model with different availability zones, different regions, etc. But the Check Point product was a little bit behind in the past. 

The convergence time between cluster members is still not perfect. It's far away from what we get in traditional appliances. If a company wants to move mission-critical applications for an environment to the cloud, it somehow has to accept that it could have downtime of up to 40 seconds, until cluster members switch virtual IP addresses between themselves and start accepting the traffic. That is a little bit too high in my opinion. It's not fully Check Point's fault, because it's a hybrid mechanism with AWS. The blame is 50/50.

I have been using CloudGuard IaaS for close to one year.

In terms of the stability, so far everything is good. We have had no problems. 

The scalability is also great. It's not complicated to configure it and the environment can become really scalable. Everything can be auto-provisioned: instances created, policies pushed, licenses installed. Check Point did a great job in covering all these aspects and reducing manual intervention, which is how it is supposed to be on the cloud.

It is deployed in all AWS regions and we plan to increase the number of security features in use in the future.

Check Point's technical support is great. We are a Diamond customer, meaning we have the highest level of support available from them. We always have very competent engineers and the right level of attention. We haven't had an opportunity to test technical support regarding this product, but in general we are happy with technical support we get.

We did not have a similar previous solution. 

The favorable results of its security effectiveness score from third-party lab tests were not a major part of our consideration because Check Point is a known leader. There were no doubts about security.

As for the solution being a leader for many years in industry reviews of network firewalls, it is important to go with a solution that not only has good specs on paper, but also has a known record of success.

The setup process offered by Check Point is quite straightforward. The challenge is that there is no single blueprint for an organization, and that's why each and every company chooses its own design for the cloud. That means we have to be creative and start adjusting whatever Check Point provided as a setup guide, for our needs.

Setting up a working environment took us approximately 10 days.

Our implementation strategy was quite simple. We first needed to understand the business needs and what the stakeholders wanted us to deliver. Based on that we created a design draft: How to proceed with the least complexity, the best way to provide connectivity, and obviously, to do everything in a secure way. After creating a high-level draft, we started our work. Since the environment was not really in production yet, it was a long path of trial and error. But at the end of the day, all aspects were accounted for, lessons were learned, and we adjusted our initial design and prepared operational documentation for our operational team.

Licensing is easy since this is a virtual instance which does not require RMA.

The cloud security provided by public cloud providers is great because it's cloud-native. Sometimes it comes without an additional cost or as part of a basic license, but it's definitely not enough for an enterprise environment. Everything comes back to operational complexity. I could incorporate a new, simple tool from a public provider, but on my side it would mean I would need to up-skill team members and manage an additional layer of security, and it could be hard for troubleshooting. To integrate these tools into the peripheral systems, like sending logs, and analyzing these logs, and maintaining additional rule sets from additional dashboards, would require additional efforts.

So cloud-native security has its own disadvantages. Many companies try to stick with the simplicity whenever they define the operational flows, but I prefer choosing Check Point everywhere in a hybrid environment to make my life easier from all perspectives.

The biggest lesson I have learned from using this solution is that network security is moving away from traditional deployments and companies have to adapt themselves to stay competitive.

We are fully managing the service. As soon as a new version is released on the Check Point site, they make sure to release it for CloudGuard as well. But so far, we have stayed with our original version. We haven't done any upgrades.

The integration process between CloudGuard and AWS Transit Gateway is not straightforward, because we're not talking about traditional networking. There are a lot of different aspects that we are still not used to keeping in mind. For example, routing is completely reworked in AWS. It's just a matter of time to get used to it. Once you get used to it, everything becomes relatively easy.

In terms of our workflow when using the integration between CloudGuard and AWS Transit Gateway, we needed to review our operational documentation and prepare additional guides for our operations team on how to do it. We needed to up-skill our team members, and we needed to utilize new technologies or new features, like BGP over VPN, to make communication secure in the cloud.

The solution provides security for numerous corporate applications and is under the responsibility of the operations team which consists of about 15 people. For deployment and maintenance of the solution we have one security operations engineer, one network operations engineer, one AWS operations engineer, and one SDWAN engineer.

We mainly used CloudGuard for IPS and IDS in our AWS environment, and we also used it for additional logging to see what was going in and out of our network in AWS. We have very limited visibility, especially when it comes to logging, and AWS does not support IPS and IDS as of now.

The way they implemented their auto-provisioning, where you just change a port or a security setting on AWS and it applies it automatically to all your firewalls, is good. You don't have to go into both of your firewalls, if you have redundancy like we did. You just need to change it on one of them in AWS, and that change applies to both of the firewalls. That saved us a lot of time. Usually, on physical firewalls, if you have to do that, you're going to have to either do command line, or if you don't want to do command line you have to do console and do multiple changes everywhere, from firewall rules to access rules. With Check Point, all you have to do is one change in the AWS console, and it will apply it within your firewall. Without that we would have had to do that in AWS, then go into the SmartConsole for Check Point.

I'm the only one who does security for both our on-prem and our cloud environments. Having Check Point there, I didn't really have to do much. It gave me peace of mind that it would do its job. I did check on it on a daily basis, just to make sure everything was okay and that there was no unwanted traffic during the day or during the night before. I didn't see anything unusual and if I did see something, it was one of those one-offs because another team was doing testing or something like that.

The IPS, IDS and logging were some of the features that I found useful. Also, the automation using AWS CloudFormation, the way we deployed it to our system, was very simple.

The comprehensiveness of CloudGuard's threat prevention security, looking at the logs, was really good. It would tell me if there was any unwanted traffic on our system, it would keep track of that. We checked it to make sure that everything was okay. It gave me the information that I needed to keep our network safe.

It's also pretty user-friendly. I've used multiple firewalls, both physical and virtual, and to me, Check Point is on top when it comes to ease of use and understanding the firewall installation. It's very very simple. And the way they implemented CloudFormation and the auto provisioning, is hands-down one of the best.

We did not use the AWS Transit Gateway, and that's one of the things that we're currently using. I believe we will be working with Check Point again, in the near future, to implement it, once they start having proper support for a single customer with multiple accounts. When we were using them, we had to install Check Point on each and every single account.

I believe they're working on a solution for that. I know they're utilizing Transit Gateway for it, and that is exactly what we're using right now. I'm excited for them to have that ready, and for us to put it in our system.

In general, cloud infrastructure or a cloud-based environment, is very fast when it comes to technology. Things get developed right away. Check Point just needs to adapt to those changes quicker.

We used Check Point CloudGuard IaaS for over two years. We stopped using it about six to eight months ago. Our environment basically expanded to such a large scale that it wasn't feasible for us to use CloudGuard in our multiple-account production environment.

We are definitely planning on redeploying CloudGuard at some point because we always need IPS and IDS and better logging. AWS only has two or three companies that do IPS/IDS. We definitely need those kinds of protection and Check Point, in my opinion, is one of the best so I still want to put it in place. But their solution doesn't really match our requirements. That's the only reason we moved away from Check Point.

Its stability was really good.

They do implement Auto Scaling and that was one of the requirements that I asked them about. One of their southbound firewalls did not have Auto Scaling at that time, so that's why I requested it.

The scalability is very good; again, very user-friendly. I wouldn't even say "user-friendly" because, as long as you deploy it properly, you can kill an EC2 and it will spin up another one right away, within about a minute and a half. And it will be ready for production right away.

Our production environment never decreased, it only increased. Our presence in AWS quadrupled over the time that we used CloudGuard. I'm managing about 32 accounts that, obviously, need protection. Once they implement that particular solution, we'll be very happy to have them integrated within our environment.

The number of users of CloudGuard, because we had deployed it in our production environment, was as many customers as we had. All traffic went through CloudGuard.

I never dealt with tech support. I dealt more with our account manager. We never had issues with Check Point, so I never had a chance to talk to their support.

We were using native AWS protection.

The initial deployment wasn't too complicated because they had CloudFormation. The only thing that I had issues with was having to integrate that within our company's requirements. Our needs kept changing because we were new to AWS. But that was not an issue with Check Point. And once the requirements within the company had been solidified, we deployed the solution to four or five environments in our AWS and it was fine throughout. We even did their second version of CloudGuard, and again, it was easy.

It's pretty straightforward. It's literally just a matter of selecting the right version of Check Point, your VPC, your management, your password, and that's pretty much it. It's pretty simple.

With the way AWS does things, our deployment took about half a day. And that was mainly because there were dependencies on CloudFormation, where it would wait for a task to finish, and AWS depends on the region that you're in. If you pick a very busy region, then it takes longer than usual. So half a day is giving it padding, in terms of time.

Once it was up and running, it required just me for maintenance.

I was the only one from our organization involved with the deployment.

In the initial installation, the first time, I was working with a Check Point engineer, because we were new to AWS and the Check Point integration with AWS. We came from Azure. We needed somebody just to make sure that we were doing the right thing. But after that, we never needed Check Point support. They would check in on us, just to make sure everything was good.

The engineer was really good. He was there to walk us through and to make sure we understood every piece of the deployment. After that, I put together some documentation based on our needs. From then on, future deployment was fairly simple.

The ROI is in the number of people managing it. Technically, you don't need to manage it. If you have an on-prem, you constantly need to manage the firewall. You need to make sure everything is okay, when it comes to hardware, software, and managing the actual firewall. With CloudGuard on the cloud, we eliminated two of the three. We didn't need to care about the hardware or about the software upgrades. If we did need to upgrade, it was just with respect to CloudFormation. We didn't need to do any firmware. The only thing we needed to do was manage an interface, which is what you're going to do anyway. 

You only need just one person to do it. When it comes to return on investment, you don't need to hire a full team to manage your whole network. If you have a firewall team, with Check Point CloudGuard, you don't need it anymore. It's just a single person because, if a Check Point goes down, it gets spun up right away. You don't need to call anybody or order hardware or anything like that.

Pricing of CloudGuard is pretty fair when you have a single account. It's comparable with other cloud providers. But for our use case, it got really pricey when we had to deploy multiple CloudGuards on multiple accounts in different regions, because you can't have CloudGuard protecting multiple regions. That's the big thing.

Before picking Check Point, I checked Cisco, Fortinet, and Palo Alto. At that moment, when we were doing a PoC, Check Point was ahead of them when it comes to implementation, deployment, and ease of use.

Deployment was the big thing for us because we knew that we were going to be deploying this multiple times. We wanted redundancy, and ease of use and deployment. Check Point nailed those top-three requirements, so it was the clear choice for us. The others didn't have the robust capabilities of Check Point or CloudGuard, to do the things that we wanted. Those included ease of deployment using CloudFormation, scalability using Auto Scaling and the auto-provisioning within CloudGuard.

My advice: Get it. It's a great product. It's a great solution.

In terms of CloudGuard's block rate, malware prevention rate, and exploit resistance rate, we didn't really do much testing when it comes to those types of scenarios. But I've used Check Point as a physical firewall before, and it was great. It detected threats and gave me an alert as soon as it detected them. It was really good.

We have an AWS environment with servers and resources. We also have a Cloud environment and CloudGuard is our solution to protect the internet access to and from the database environment. For example, servers on the AWS that need to do upgrades go to the internet and cross the CloudGuard solution. People that need to connect to the AWS environment, to a server are protected by CloudGuard. The environment is protected by CloudGuard. It's our perimeter firewall on the AWS environment.

We were already used to Check Point products and we needed to protect the AWS environment. It was very straightforward. We could use the same policies that we use on-prem. We were already used to the logs, for the kinds of things Check Point shows in terms of what is crossing to the internet. We didn't need to get used to a new kind of log that we were not used to. It saved us a lot of time. We were able to seamlessly extend our on-premise protection to Cloud and didn't require any effort.

Two years ago, we didn't know what the best way was to protect the environment but we found out that we could use the same kind of protection that we use on-prem. It helped our security team to be confident that the cloud environment is protected. 

The use of unified security management has freed up security engineers to perform more important tasks. We saved a lot of time, especially managing the threat prevention profiles because when we want to do some kind of exception or enable a new kind of protection, we can enable it on all our firewalls, not only the AWS but also on the on-prem firewalls at the same time using the same profile. That helps us a lot and saves us a lot of time because we don't need to go to the AWS protection to do stuff and then to the other premise. It saves at least four hours a week.

Compared to the security provided by AWS, CloudGuard is very easy to understand why something is being blocked. We can see it on the SmartConsole for Check Point, which is one of our favorite products for security. It's much easier to understand what and why something is happening. 

The most valuable feature is that we can use the same manager server that we use on our own Check Point firewalls. We integrated CloudGuard on that manager and we can use the same kind of protections that we use on the on-prem firewalls, like the IPS and antivirus policy. We can have the same kind of protection on the Cloud environment that we have on-premise.

• The block rate is good. It's what we used on-prem. We feel protected by the Check Point threat prevention that we used for many years. We are confident that it blocks everything that needs to be blocked.
• Malware prevention is also a good feature. It's the same kind of malware prevention we use on-prem and we never had any issues. We have used on-prem prevention for many years. 
• Exploit resistance rate - we never had any problems with it. We never had any security issues due to exploits on our diverse infrastructure.

In terms of the comprehensiveness of its threat prevention security, it was very easy for us to start working with because it's the same. Check Point has a very wide group of protections, dozens of protections. It's very good in terms of protection.

CloudGuard is very good in terms of ease of use, especially because it's very easy to understand the blocks and why something was blocked. You can see in a log why something was blocked, if it was identified as some kind of malware or suspicious activity. You can immediately see on the log the rule or the threat prevention policy that was blocking it if you want to do some kind of exception, or if you want to verify why. And it's very well documented with the description of the threat and why it should be blocked.

CloudGuard functions just like any other firewall. It functions very well. The only thing that could maybe be improved would be to integrate some tools that are not integrated with the SmartConsole, like the SmartView Monitor that we need to open on a different application to access.

I have been using CloudGuard IaaS for two years. 

It was always very stable, so we deployed it and now we only manage the policy, the application control, and the IPS. In terms of stability, it's very stable.

Its scalability is one of the best features because of the auto-scaling groups.

There are three users in the company who are all network security engineers.

It's has a 100% adoption rate. Our Cloud environment goes to the internet through the CloudGuard solution.

Support is good. We never had anything that they couldn't help us with.

We did the deployment with vendor support. It's not straightforward, especially because the solution was fairly new when we started to deploy. There wasn't a lot of the commutation that there is now. We had help through remote sessions and the vendor. We managed to do it, but it's not very straightforward.

We had to get used to the concept. We use the auto-scaling groups, which is when there is low internet access needs, we only have one gateway. And when a lot of people access the internet, the product automatically generates more visual firewalls. This was a different concept than what we have on-premises, of course, because this is not what's on-prem. The concept of auto-scaling groups was something we needed to get used to.

It saves us money because if for example, we have three firewalls running but at night, no one is working, the internet access is very low. The solution automatically reduces the number of instances to one, which is the minimum. Then, if someone is doing a lot of things that need internet access, it automatically spins more instances. This saves us money.

The deployment took one week.

The implementation strategy was to first do a proof of concept, only for our Dev VPC. Only the Dev VPC was using the internet through this solution, and then when we were confident that it worked as we thought it should work. We deployed it in all our accounts, production, and corporate.

We are aware of the overall perspective of the Check Point security products and the rates. We were already aware that it meets the ones that we use on-prem. So we are always aware of those results. 

The fact that CloudGuard has been a leader for many years in industry reviews of network firewalls was also important, but the most important thing was that we can also use it on-prem and we are satisfied with it. 

The consultants were very helpful. 

Pricing for these kinds of products is always expensive but I would say that it's in line with the competition.

We didn't evaluate other solutions because it was a good fit for us and not worth evaluating other solutions.

If you are already a Check Point customer, this is the perfect solution. If you are not used to Check Point products, you should also analyze other solutions and compare them before you buy.

The biggest lesson I have learned is that with this product, you can secure the Cloud environment the same way that you secure the on-prem, which helps a lot with people that are new to the Cloud security environment.

I would rate Check Point CloudGuard IaaS a ten out of ten. 

We are a small consulting company. We have around 100 employees. We don't use advanced firewalls because we don't really have important data that can be hacked. Nobody is going to care about our data because it's only the HR department's timesheet data on our on-premise systems. The firewall is protecting remote access, allowing the employees to access our office environment. So sometimes employees connect to our systems which have some test systems on it. They run some tests about the consulting we've given to clients. That's all. We just have basic things on our firewall. Just two things are important for us - the site to site VPN, which we have with some customers, and the government site. That is important. That's why I want to change the firewall to a new and up-to-date one so maybe it will be an improvement to prevent some hackers.

After I made up my mind to migrate it to another solution, I was kind of checking all the other firewalls, the FortiGate, Check Point, pfSense and OPNsense, and Check Point has pretty simple solutions, like the virtual appliance which you just download and it is imported into VMware and you just start using it. You just have to know Check Point's GUI so you can manage your IP addresses and access rules and stuff. But as I said, Check Point is really advanced and the GUI is kind of advanced, which the customer reports actually prove.

In terms of what could be improved, we have no support with the current Check Point environment. It ended maybe three or four years ago. Because it's an appliance you have to have support. That's a problem for us because I cannot update it at the moment. We have to have another support. We have to subscribe to another support so I can update it. I think it's a good amount of money and our boss does not want to pay that kind of money for firewall solutions. It's not a hardware solution, which by the way, if it would be up to me, I would migrate it to a hardware FortiGate system because all our customers at the moment are migrating their environments to FortiGate hardware solutions. They say it's a really good improvement from their previous firewall solution because it's easy to manage and they're very happy with it.

But as I said before, my boss does not want to pay a lot of money for a firewall solution since we don't have much data to protect and the data is not very important. It's not a big use for us. So we will just probably try pfSense or OPNsense. I can patch it to an up-to-date version, like the 2021 patch. We have the open source solution because my boss does not want to pay for it. It's my approach to migrate the firewall, actually. If it was up to me, I'd probably migrate it to a FortiGate system.

I'm not very experienced with Check Point. But what I would like to see is a step-by-step initial installation of the firewall. That would be really helpful. Like in Oracle appliances, when you start it asks you, what's your current IP address? An initial setup should be a step by step and intuitive process. You click on "begin," it asks you some simple questions. You fill in the blanks - your current IP address, what you want to do, if you want to set up a site to site VPN, for example, that kind of thing. That would be the smartest thing to have.

I can't give it any review about Check Point technical support because I am only working here for about three years and by the time I started at the company it already did not have support.

I have no idea about the initial setup, but it seems like it's not so complex. The initial set up is probably not that hard, but not that easy, either. If I were to delegate the firewall system to a junior guy, I think that he's not going to manage Check Point, but he'll probably manage FortiGate.

In the past, my clients were all using Check Point Systems. When I reviewed it at that time, back 10 years ago, Check Point was number one, as far as I remember, meaning FortiGate wasn't a major solution in Turkey. Nobody was talking about FortiGate then. Now FortiGate, is a major player in the firewall industry in Turkey. Most of our clients are migrating to FortiGate because they say it's cheaper than Check Point. So when I see the Check Point's GUI, it's really complicated. My recommendation would be for Check Point customers to first learn about Check Point's GUI, which is pretty advanced, for me at least.

But when I talk to my friends who are managing IT, they are migrating to FortiGate. They say, FortiGate is very easy to manage and I should really think about it now. When I was first introduced to Check Point it was really advanced. I didn't understand when I first looked into it. I just wanted a solution. pfSense has the same problem. By the way, according to your report, some customers said that pfSense needs improvement on the management and the GUI and aspects like that, so maybe I'll need another review of OPNsense versus Check Point and FortiGate etc...

We didn't have any problems at all. Just in one case, actually. We have a rule that pops up from nowhere which we didn't create. When we restart our Virtual System firewall, it creates a rule which messes up all our internet connection. So if I were to give a number from one to 10, I would probably say Check Point is a nine out of 10. Other than that, we haven't had any problems. Check Point is pretty reliable. I think it's our company's problem that we couldn't patch it after it froze. Maybe an up to date, patched version doesn't have this problem. 

Overall, it's really working for us. I don't have any problems other than it's just outdated.

The main usage of the Check Point CloudGuard IaaS within our company is for the protection of our cloud assets. It is deployed on Google Cloud Platform with the help of the Firewall, Application Control, and Intrusion Prevention System software blades. 

In addition, we rely heavily on the GeoIP module to restrict undesired countries from accessing our services, as for now, you can't achieve it with the GCP firewall.

There are about 30 Google Cloud projects of different sizes ranging from 10 to 250 virtual machines, and they are used for development, staging, production, etc. For every project, there is one dedicated scalable instance group of the Check Point CloudGuard IaaS gateways.

While using the Check Point CloudGuard IaaS gateways in the cloud environment, we had almost the same experience as with other Check Point firewall solutions.

The components of the infrastructure are integrated with each other quite well. All the common Check Point Next Generation Firewall blades are supported including Firewall, IPS, Antivirus, VPN, etc. There is not a big difference with the usual on-premises gateway from this perspective. This provided us a smooth experience while moving our load from on-premises data centers to the Google Cloud environments, and increased the adoption and the speed of the migration process.

I find it really useful that CloudGuard supports all the main players on the Public Clouds market including AWS, GCP, and Azure, as well as some exotic ones like Alibaba Cloud, Oracle Cloud, and IBM Cloud. I would say there is about a 95% probability that the platform you are using is supported, and I don't know any other solution for now that can provide the same number. Moreover, it integrates with most of the public cloud management solutions, so you could automate modification of the security policies based on some triggers or changes in your cloud infrastructure.

I also like that different licensing models are supported. For testing/evaluation/PoC projects, you could go with the Pay-as-you-go (PAYG) license without wasting a lot of money in case the solution somehow doesn't suit you. On the other hand, for production, you could use the Bring-your-own-license (BYOL) way, applying the license bought earlier.

As with other solutions of this kind, you still have to manage basic cloud firewalls and routes for VPC outside of CloudGuard IaaS. There's no 100% integration.

I hope that Check Point continues to improve its technical documentation regarding the Check Point CloudGuard IaaS gateway and management system. For example, the questions on how to scale the instances in the relevant cloud should be covered, and all the High Availability options and switchover scenarios. Without that, users have to open numerous consulting cases to the support team to get it right.

We have been using Check Point CloudGuard IaaS for less than a year.

The Check Point CloudGuard IaaS is stable product, and in fact it runs the same code as the hardware Check Point NGFWs, so no issues were encountered there.

The Check Point CloudGuard IaaS scales well for the Google Cloud Platform with the help of the Instance Groups feature.

We have had several support cases opened. Some of the issues were resolved by installing the latest recommended JumoHotfix, whereas some required additional configuration on the OS kernel level.

The longest issue took about one month to be resolved, which we consider too long.

We didn't use such solutions before and had to rely on the built-in firewall rules of the Google Cloud Platform infrastructure.

The setup was straightforward, and the configuration was easy and understandable.

Our deployment was completed by our in-house team. We have a Check Point Certified engineer working in the engineering team.

There is flexibility in the different licensing models that are offered.

For testing/evaluation/PoC projects, you could go with the Pay-as-you-go (PAYG) license without wasting a lot of money in case the solution somehow doesn't suit you. On the other hand, for production, you could use the Bring-your-own-license (BYOL) way, applying the license bought earlier.

This is a flexible approach and we like that.

No, since we decided to have a unified firewalling solution across all the infrastructure, and we already had the Check Point firewalls in the on-premises data centers.

You should fully understand the way CloudGuard would be integrated into your cloud from a networking perspective, and it differs from platform to platform. For example, for Google Cloud, the instances of Cloud Guard must have interfaces in several VPCs as a requirement. Think about the subnetting and routing for your project, then implement a PoC with your networking staff.