Tufin Orchestration Suite Reviews

Our primary use case for this solution is risk visibility.

We use this solution to clean up our firewall policies.

Prior to using this solution, and according to our best practices, we didn't have a baseline of the security poster that we have with our rule sets. Now, with this reporting, we're able to provide that to our management.

It has helped us meet your compliance mandates. We are getting this from the data and reports. This was one of our requirements.

The most valuable feature is the reporting of our risk poster in our firewall. We clean up our firewall rules using this solution. The reporting helps us carry this out quickly.

This visibility is good and I would say that the change workflow process is average to good.

We expect that SecureChange will help us to reduce the time it takes to make changes. It is on our roadmap.

The reporting still has a lot of improvements to be made.

I would like to see improved role-based access. 

For us, this product has been very stable. We don't have any trouble with it.

Our deployment is quite small, so I cannot speak to the scalability yet.

Technical support for this solution needs improvement. We usually get a callback from an engineer, but the escalation of support should be faster.

Our account manager at Tufin is very engaged and has been super helpful.

Adopting this solution was an easy decision for us because it is an audit requirement.

The initial setup of this solution is straightforward. Installing SecureTrack was not difficult, after browsing through the knowledge base. With the documentation that is available, it is easy to deploy.

We implemented this solution ourselves.

We have not yet seen ROI, but when we go with the SecureChange model, we will automate and reduce overtime hours. At this point, we will see a very valuable return on investment. For the time being, it is on our roadmap.

We did evaluate other solutions before choosing Tufin. This solution is used by many large companies, which is one of the reasons that we selected it.

There is always room for improvement, but with the performance and the day to day stability that we have, I think that it's a very good product. Overall, I am very happy and satisfied with the product, and I am looking forward to a lot of new features.

I would rate this solution an eight out of ten.

Our primary use case was firewall policy management. We did a PoC with Tufin.

There was no issue with slowness, especially when it came to pulling the data in real-time.

Tufin was able to automatically check if a change request would violate any security policy rules. During our PoC I tested it by trying to do unauthorized changes and Tufin met our requirements.

We are looking to become ISO 27001 certified for information security management. We need a solution like this for the audit side. They need to be able to check our firewall policies.

The goal was policy management and Tufin's policy management features met our requirements. It allowed us to crosscheck policies.

I like the fact that Tufin was able to integrate with our firewalls, which include Palo Alto and FortiGate.

I work on the network and security sides. The network visibility side needs improvement. I need to be able to see what the configuration changes are inside. On the firewall side, there are no visibility issues.

Also, I'm not sure if it integrates with Riverbed.

So far we have had no issues. We're running it on a VM and there are no issues with the VM.

We had no issues with scalability.

We are a big company and our network is complex. We have a lot of servers and we have about 700-plus branches connecting to HQ. HQ is our main site to go with the ISP. But we only implemented Tufin at our HQ and two of our main branches.

There were only four users on my team.

I did not engage with Tufin's technical support. We used a third-party.

The setup was not too complex but not completely straightforward. It was so-so, at least for our environment.

We had an issue with how to push the policy changes. It took about a week, during which our engineer conferred with Tufin. Tufin had to do some fine-tuning.

In terms of an implementation strategy, at that time we were only doing a PoC to see the policy management functionality. Tufin can also integrate networking and security to show an overall network mapping, from site to site. We have a lot of branches. And we are now moving to SD-WAN, to see the mapping. We need to see if Tufin can integrate with that.

On the technical side, the Tufin solution was very helpful for my team. It would save my team time. Using Tufin they could check all the firewall policies in one console, for both Palo Alto and FortiGate, at the same time.

There is no issue with the pricing because we used a VM. That kept the cost low, as compared to an appliance. The licensing cost quote met our budget.

We have done other PoCs with AlgoSec and FireMon. But as we compared Tufin with them I preferred Tufin rather than AlgoSec. They were basically the same, but then Tufin came out with a lot of changes in their recent update. Also, Tufin is real-time while AlgoSec is near-real-time, for policy management.

In terms of advice, it depends on what a user's needs are. For us, we only considered Tufin for the security and the network parts, especially the network mapping. I need to see the hop-by-hop, from this site to that site, how many hops for a transfer packet. 

Tufin is good for beginners. Tufin filters based on rules, even if a beginner doesn't know what to do, how to configure the firewall. Tufin can then monitor based on those rules.

It's a good value for what it does. We had no issues with this product. It was good for us. We could deploy it in our environment without any issue.

I rate it at eight out of ten because we are still evaluating Tufin. Our project is running on Riverbed for SDN. I don't know if Tufin can integrate with Riverbed. Other than that, I have no issues with this product.

We are doing firewall automation through Tufin.

In terms of the change impact analysis capabilities of this solution, we get a lot of CNR queues and it has saved a lot of time when making changes. And the analysis tells us that we have made a particular change and it sends out a lot of alerts. We can analyze them and do some auditing stuff as well with Tufin.

We have a lot of teams that do stuff in Tufin, management teams, auditing staff, and a team for implementation. So the time it saves us across that whole scenario is hard to pin down, but it has saved us a lot of hours in implementing the CNR queues, approximately 20 to 30 hours a week. That a big time savings.

The solution will automatically check if a change request will violate any security policy rules. We have an auditing staff using this feature within Tufin. If we have an open rule, it will send us an alert and we can see why this alert has been sent and take action on it.

Tufin helps us ensure that security policy is followed across our entire hybrid network. We can set up rules and policies for this and we can do a lot of auditing as a result.

The topology and the config backup that we see for devices are key features we get from Tufin.

The change workflow process is flexible and customizable. We went through a lot of difficulties while doing stuff, and it now provides a lot of flexibility while making changes. We can go back and implement the changes again and that is one of the things that is very flexible. If we have a firewall completed and we want to redo it, if we need to re-engineer a particular firewall and open a different destination, we can do that by creating a break-fix. A break-fix is one of the things that we can use to redo things on Tufin, itself. That is one of its useful tools.

Auditing is another good tool within Tufin. The automation stuff and searching of reports are good for auditing as well.

I have gone over compliance issues in Tufin, but compliance is one of the things which might not be that clear in Tufin. It just shows the configuration. That is one of the things they have to work on. It is one of the constraints, in my opinion.

The topology is good but they could work on it and get something better out of it.

If we talk about the complexity of getting more nodes over Tufin, Tomcat or web services become flat. This is one of the constraints that I have seen. The web services are not that stable. This has to be checked and taken care of.

If you have a normal load in Tufin it works perfectly fine. But they need to work on the stability because if a certain amount of load is put in Tufin it just breaks downs, from what I've seen lately. That has to be taken care of. The parameters for the platform also matter in that situation, but if they can work on the stability, that would be great.

The scalability is fine but when it comes to web services, in my experience, Tomcat has always gone down; after a certain amount of load it breaks down and we have to get things restored again. The scalability is perfectly fine but, performance-wise, they have to work on the platform or the base of Tufin to make it more robust. In a bad situation, if a lot of guys are logging in, it breaks down.

Although I am in India, we have U.S. support. I haven't had any interactions directly with tech support, but one of my counterparts in the U.S. talks to them and sorts things out for us. I haven't had any discussions with them where I can analyze their work.

It was challenging at the time because we wanted to implement a lot of things which Tufin doesn't have as default. There was a lot of customization required and it took a lot of time - one or two months - to sort that out.

We did not have a previous solution. We were moving towards automation and we wanted something that would save time in doing firewall queues and creating firewall rules. We were looking for a good tool and Tufin was one of them. It is a multipurpose tool that gives us topologies, and auditing and alerting.

I don't think we had any issues installing it. That was not a problem. It is not that difficult but it is not easy either. The setup was normal and I wouldn't complain about it.

Our deployment took about ten to 15 days to get things onboarded. There were many other guys who were also involved in it and I don't remember entirely, but I think that's how long it took to onboard things.

The number of people involved in the deployment depends on the infrastructure and what kind of services you are looking for. If you're looking at server management, that would require one or two guys. If you're looking at onboarding of devices, you would need another one or two guys. For the auditing stuff, again, another one or two guys could do it. So for each of these areas, one or a maximum of two guys could handle it. Once you are done with onboarding, managing it takes two guys.

Regarding our implementation strategy, our primary motive was to get firewall automation in place. With that in mind, we worked to bring in all the devices and all the firewalls. Then we started talking about getting the different packages over to it and working to get the firewall automation done. There were a lot of things we had to do - it took months - when we had to bring in new patches or requests.

It was Tufin only and one or two guys within our team. There was no third-party involved.

Firewall automation was one of the biggest concerns we had, and we have largely sorted that out with this tool. If we are saving hours, then we are saving money.

I was involved with the pricing at the start. But then management took over that issue. In terms of affordability, this company is using it, so it seems they are fine with it. We just provide management with our requirements and it's their concern and responsibility to bring us what we need. Since we still have this solution, I think they are fine with it. But it's a management call.

My advice would depend on what kind of implementation and what kind of environment you have. If you are looking for automation and auditing you should think about this solution. Talk to the technical guys at Tufin about how your environment works and can ask them about what they can do. If you are looking for automation you should look at Tufin.

Regarding Tufin's cloud-native security features, I am only familiar with their on-prem stuff. I haven't seen any of the cloud features on Tufin yet. I would really like to know what it will bring us at the end of the day.

We have three or four teams using it on different platforms and for different use cases, like auditing and alerting. On my team there are 25 guys using it. I don't have any idea how many guys on other teams are using it. Our security area is managing and maintaining it.

As engineers, we are certainly using it daily. I just made a scheduled change today through Tufin. We are certainly using it but I can't say what our plans are for it in the future.

I would rate Tufin at seven out of ten. The things that come to mind with this rating are the implementation of firewalls, the alerting and security. We can set out the security rules. I deducted three points because of the platform. I don't think that it has a stable platform. If there are 20 people and 22 need it, it will not be able to support us in that scenario. So that is a weak point. Stability and robustness are the things I'm looking for.

Our primary use case for this solution is for audit and firewall rule base management. 

Tufin allows us to perform self-audits and use rule-based accountability. 

The most valuable features are the Security Risks and Best Practices reporting/Rule base cleanup.

I feel that the user interface is a bit dated. The product version updates should be automated, and the reports could be a bit cleaner.

We deployed a proof of concept. We added most of our firewall base to Tufin, although not all. We checked and tested Check Point, Palo Alto, Juniper, Cisco routers, Juniper routers, and F5 load balancers. Mostly we grabbed one instance of each of our technology devices, added it to Tufin, and tried different things. We tried SecureTrack and some basic SecureChange to try to automate our firewall partitions, the firewall "tickets." We presented a form to users to enter the source, destination, service, etc. This was our PoC.

Right now, we're in the process of purchasing Tufin.

With path analysis, you can specify a source, a destination, and a port and it will tell you whether it's blocked or not, and where; which firewall is doing the blocking or the allowing, or whatever. That part is very useful. When you have feedback from the user and you have your source, destination, and port, instead of trying to search on the Check Point console or the Panorama console or the Juniper console to figure out where that packet being dropped, you go to Tufin, put it in and, in 30 seconds, you have your answer. 

It saves time on each ticket. Instead of playing around for 15 or 20 minutes, it's down to 30 seconds. Any first-line of support can go to Tufin, put in the source, destination, and port and they can at least know what to look for, who to involve to further troubleshoot the issue. It's a first-step investigation that saves time.

It also helps us ensure that our security policies are followed across our entire hybrid network.

SecureChange is the most interesting part. It all comes down to having the user request firewall access and SecureChange, based on workflows, takes care of it, sending two or three emails to the business approvers. With one click, you can automate a firewall rule. We have many problems like, I imagine, the whole industry, with delays in implementing firewall rules.

SecureTrack provides all these regulations, PCI kinds of things, so you can try to match all your security policies and firewall configuration to the standard. 

There is also a feature to optimize firewall policies that will delete duplicate objects and rearrange the rules so the machine will function faster.

In addition, the change impact analysis capabilities allow you to do automatic checks of whatever rules you are implementing.

Finally, the change workflow process is flexible and customizable. I was really impressed with it. It's pretty easy. You can add automatic validation steps. Depending on the security matrix, you can pre-allow whatever flow you want. You can do your change analysis automatically or risk analysis automatically; whichever steps you want. It's pretty cool.

The visibility that Tufin provides us with is improvable. The interface is like a 1990s kind of thing. It's a little ugly. There are many things that you cannot tweak, little things like the column width and how you display the information. You end up exporting everything to an Excel file and doing your work there. They tried to put too much stuff on the screen. It's a little difficult to find what we want. It's a design issue, it's not a functionality issue.

The web interface is really like going back in time 20 years. You have to move columns back and forth and make them big to see the whole text in them. If you hover over a name, it won't show the content. You have to click on it and open it. It's a bit cumbersome.

The documentation site is horrible as well. It has a tree structure, and you really get lost quite easily. If you have the patience to browse through that hell of documentation, you will find what you need, but it is hell to browse and search. The information is there, it's just difficult to filter and search it. Documentation is one thing they can improve on.

I haven't found any issues with the stability. In the beginning, it was our problem, our mistake, because we configured the box with eight gigs of RAM. Then we checked and, obviously, we needed 16. After enlarging it to 16, there was no issue whatsoever. It was pretty responsive. Obviously, it was only one user, me, doing things, but I didn't find any issues performance-wise or stability-wise.

We don't have that big of an environment. We added some 20 pairs of firewalls and another 20 or 30 routers, and one F5. I don't think we have scaled Tufin sufficiently to put it under some stress. Our DC is pretty small, we don't have many devices.

Tufin's technical support is excellent. In my old job, I also implemented Tufin, and I was in touch with their Israeli people, the technicians; they're really good. They really know their stuff. In Spain, for southern Europe, they have a couple of people. The technician there is excellent, and the commercial guy is fun. It's the perfect combination.

The setup was straightforward, absolutely. The only problem we had was with Check Point, but I think it's a Check Point problem, not a Tufin problem. Check Point is horribly configured. Managing it is hell. You have to define the OPSEC server with a user name and password, and you have to create the same thing on the provider one. They have to be same user but have different passwords. It's a little difficult. You have to pay close attention so you don't make a mistake. But I think that's a Check Point issue, not a Tufin issue.

The whole Tufin deployment took us about four months, with SecureChange, etc.

Up to the point with Check Point, it was easy. We created a read-only user for our infrastructure, and once we had connectivity from the Tufin box to all the devices, it was pretty simple. It was just IP address of the device, username, password, and go. Except Check Point. We needed to spend a day or two on that.

In terms of our implementation strategy, we wanted to test each of our technology manufacturers: F5, Check Point, Palo Alto, etc. We left our main public-facing networks out of the equation for the PoC. Whenever we implement the whole thing, we will include those. We made SecureTrack work well. We will define our security matrix correctly with all our networks, as granular as we would like it to be. Once we have that, we will go to SecureChange. So it's SecureTrack, do a good security matrix and, once we're confident with that, we'll go to SecureChange.

For deployment, it was just myself and the people who deployed the VM, with the help of Tufin's team. I'm the only one who was involved in maintaining it.

Tufin's team helped us mainly with the Check Point stuff when we ran into some problems.

In a PoC it's difficult to see ROI. Seeing how the tool performs, I think we will see a return on investment, of course.

It's not that expensive, except for Security Groups. For us, just the Security Groups were about half of the total price. The total was about €500,000 a year, of which €200,000 was for Security Groups. For the rest, it's not that expensive, given all the benefits we will get and all the time we will save.

We could only test AlgoSec for a little while. Our group is part of a larger group of products. When we were doing our PoC for AlgoSec, we were told to stop. The decision was made to move to Tufin because it has group-wise technology, chosen for the acclimation of firewall policies.

AlgoSec is much prettier, it's much simpler, and has a cleaner interface. Functionality-wise, it's pretty similar, from what I read in the AlgoSec documentation. Tufin has a few extra features, but AlgoSec is much cleaner, it's prettier.

Going with Tufin was not a technical decision, it was "politics." The largest group uses Tufin, so other group members have to use Tufin as well. It's mandatory.

Don't bother with the web interface, calm down, don't worry, everything will be fine. They will improve it. The rest of it, I don't have any issues. They're technically prepared, the tool does its thing. The only two things I would be patient with are the web interface and that documentation which is not really well organized. Besides that, it's pretty easy. It's pretty easy to configure and, once you start using it, you will see the potential. AlgoSec, Skybox, and all those tools probably have the potential as well. But Tufin is easy enough for everybody.

What we don't use, and what we are not planning to use, is the third module, the SecureApp. We haven't played with it and we're not planning on using it, for the moment.

In terms of using Tufin to automatically check if change requests will violate any security policy rules, we would love to do that. What we didn't do is build the security matrix. That part is the one that takes a lot of time to build. You have to work with the security team and all the players involved. Because we did not design the security matrix, we couldn't match a firewall rule with the security matrix and say, "Okay", or "Not okay," and do some automation there.

What we did is prepare a form for a firewall petition, and some automatic steps. For instance, in the first step, you enter the request and it sends an email to a business approver. Depending on whether that firewall or that flow is predefined as allowed or not, you can skip that step and go to the next step. We did a little bit of logic with the change-request form. It worked pretty well for us.

The purchasing process takes a little bit of time because of all the different groups involved. But we're planning on implementing it and to finish around next summer, 2020; to have both SecureTrack and SecureChange up and running.

As for compliance, we don't have many requirements. Of course, we are bound to some ISO certifications, because it's the car industry, but we don't have any specific PCI. We don't sell cars over the internet, so we don't have to do that.

When it comes to Tufin's cloud-native security features, what we have is our landing zone in AWS - a VPN tunnel from on-premise to Amazon, with Transit VPC. We have a couple of Palo Altos, securing the track from on-premise to the cloud. And we added those Palo Altos to Tufin. We needed to tweak and include some virtual devices in Tufin so the routing would be okay. But that was quite easy. It was well-documented as well.

The only problem is that we got our quotation from our supplier, and the Security Groups are extremely expensive. They bill you $1,200 dollars per Security Group per year, which is really high. We're not that big, we may have 100 or 150 Security Groups. That's would be about $200,000 just to manage Security Groups. We were put off by that. From the start, we won't have the Security Group feature. We think it's too expensive.

As for increasing our usage of Tufin, we'll go day by day and see how it responds to our requirements. SecureTrack at the beginning, then SecureChange. Maybe, if everything goes well, we will think about SecureApp. It's not in the scope at the moment, but maybe we will implement it.

I would rate Tufin a seven out of ten. It will get better once they get their act together with the documentation and the interface.

We are using Tufin to generate reports on unused rules and for compliance reporting.

In our environment we have two data centers which have the same IP address for service in both. This means that in data center A, server X's IP address is the same as server X's IP address in data center B, but it's sitting in a different firewall. So we are exploring SecureChange to automate the pushing of rules in both gateways at the same time. That way we will be able to track to which firewall, in which data center, we have pushed rules.

It helps us to meet our compliance mandates because we are able to define whatever compliance we are subject to. We are a financial institution so we have to comply with PCI DSS, we have to comply with certain financial rules and regulations. We are able to do that with Tufin.

It also helps ensure that security policies are followed across our entire hybrid network. So far there have been no complaints from the auditor who is checking our firewall rules. The only exception is that, because we have so many requests in a day, some of them are not used yet by the requester. What our auditor sees is only the unused part. But we are 80 to 90 percent compliant.

Finally, I expect it will help our engineers to spend less time on manual processes, that it will cut half of the time spent looking at all the rules and validation. Currently, 70 percent of my engineers' load is looking at rule validation and requests that are not being made correctly.

We are still using only one-third of the functions that Tufin has, but SecureTrack is among the most valuable.

The most valuable function is the SecureChange where it is able to automate everything from the validation of the rules to the pushing of the rules. We are mainly using Checkpoint and Tufin together.

In addition, it's helpful that we can generate accurate and detailed rule-usage reports. That enables quick clean up.

In terms of visibility, Tufin does show all the schedules based on the usage.

Another feature I like in Tufin is that we are able to track the flow of the source and destination, passing through which level of device and which firewall. It makes our operation, our daily tasks, much easier than doing it manually for each and every request.

There is room for improvement in the speed of Tufin. It is using so many of my VM resources and yet it is still a bit slow. They need to improve how they do their database indexing. That is the main fault of Tufin right now for us. It's slow. Even though we are allocating 64 gigs of RAM, we still have to wait for a few minutes for a single report to be generated. Otherwise, it would be a perfect tool.

The stability is great. It has never gone down. The only problem is the slowness.

The stability is dependent on the devices. The part where we are having a problem now is the result of migrating to RAT which is using APIs which keep going down when our MDS has a heavy load.

In terms of scalability, the only issue is the licensing part. You have to have the correct license to go to a larger installment.

This solution is the first of its kind in our bank.

The initial setup was straightforward. I was able to deploy Tufin in a few minutes only. Integrating with devices - as we are using Checkpoint, API, Syslog - is simple.

For now, we have only installed one server, not distributed. Soon we will go for distributed, because we need to collect all the logs from all our overseas sources.

I was the only one involved in the deployment and am the only one who takes care of the maintenance and day-to-day configuration. Our firewall team will be using Tufin but they don't do the maintenance. At the moment there are about 15 users. Half of them are the firewall team and then there are a few auditors and a few people in the business unit who are monitoring the rules.

ROI is measured in engineers having time for their families and being able to have more time to do other things. It is not a specific figure, it is more a matter of how time is spent.

The current licensing scheme is quite confusing but it is clearer than the old one. If you have one MDS you just buy the MDS license and the gateway license. That's most of it.

Before this, they broke it down into VS, virtual environment, physical environment, single boxes, cluster boxes. Now the licensing part is much more straightforward. If you have ten gateways you don't need to define one as a single and another as a cluster gateway.

Pricing is quite high. We did compare it with AlgoSec but the pricing is not much different between the two.

The decision was made before I joined the organization. I don't know if they looked at competitors or not. Currently, we are looking at AlgoSec, if it can replace Tufin or compete with Tufin in terms of features.

The main differences between the two are only in the pricing and the look and feel. They both do the same thing. Both will be able to achieve our organization's targets. But in terms of look and feel, our engineers are already used to what we have. And I do prefer Tufin.

If you are looking at a large environment and a large number of policies, you really need Tufin to help you manage all the rules. We have 25 policies, and each policy has around 1,000 to 1,500 lines of rules. Managing that manually would not be easy.

We haven't started using the change impact analysis capabilities of this solution yet. We are still testing it. We are not that familiar with the process yet.

Because our team is doing cleanup every three months, we need to keep generating a report every day to have correct visibility: which rules are unused and which rules need to be removed to be optimized. We are using it quite intensively. I don't know how we can increase usage until we deploy and start using SecureChange. At that point it will be more intensive because after SecureChange everything will be automated and they will start only using and looking at the secure Tufin interface, in terms of rolling out all the requests.

We haven't seen a reduction in the time it takes to make changes yet, because we are still tweaking the SecureChange part. We will be testing it in a few months' time. We need to see integration with our ticketing system because people are making requests over HPSM and Tufin needs to be able to grab them first, before we can start to roll out SecureChange.

For us, it's more about managing the policies and having an overview of all the policies that are available, that we currently implement, and bringing them to a central console so that we can have an overview of what's going on. We deploy Tufin for one of our customers, it's not for ourselves.

The key, convincing element that made our customer go with Tufin is that they have the ability to centrally monitor and view all changes that have been made in the network, and they are able to revert any problems that they encounter, if somebody has made a problematic change.

The policy overview is valuable.

The key area for improvement is the integration to F5. One of the things that we encountered with another customer is that there were some limitations when we tried to migrate policies from F5 into Tufin. Half of the network is F5 and there were a couple of other firewalls and they're trying to centrally manage them. There were issues in terms of managing the policies for F5. It's not as seamless as it should be.

Documentation to help users integrate to an F5-type of environment would be great, so that users would understand and know the limitations, rather than having to go through a PoC and then realize that it's just not suitable for integrating F5 products.

So far, the stability has been reasonably good. We haven't encountered any major issues. Even when integrating to overseas central management systems, it has been quite seamless.

Scalability is something the customer will be exploring in the next phase.

I think that the major limitation is its ability to integrate into more products. With the common products, the older products, it integrates very well. But with the newer products, like I said, F5 for example, they do have some issues. I'm not too sure about other firewall products and other DDoS products that could be in the network.

For now, the customer is trying to integrate the product into the rest of the group. That's currently being studied by some of their overseas counterparts to see if it's suitable. The plan is that the customer intends to proliferate this across the entire network, but that step will take place over five years' time.

Technical support is excellent, I would give a big thumbs-up to the technical support team.

We didn't use a previous solution, this is our main solution.

The initial setup is reasonably straightforward and the support team is quite good. They're very helpful and they're very knowledgeable.

The deployment, overall, took about three months, in terms of studying the customer's environment and doing some consultation and a deep-dive with the Tufin consultancy team.

We are an integrator, so we have a fairly decent understanding of the product and it wasn't that difficult to deploy.

Pricing played a big part here. We didn't present AlgoSec or FireMon. We got good support from Tufin directly. We managed to position it with an effective price for the customer. The customer had evaluated other products but, due to price as well as support, they chose Tufin.

We evaluated Tufin together with FireMon and AlgoSec.

The first priority is to evaluate how expensive your firewall family is. If you have, for example, F5 then you would probably have similar problems to what we encountered with F5. But if you are deploying general firewalls, like Palo Alto and Cisco, that's fine. You have to evaluate how you are going to import existing policies and how you are going to monitor those policies when they transfer them across to be centrally managed and monitored by Tufin.

In terms of users of the solution, we set up for the customer a central admin who is the main administrator that controls the entire dashboard. In addition, there are viewers who only need to view and monitor the reports and the like. It's the IT firewall team that makes changes to the firewall and backend system. So there are three main groups of users.

We do the maintenance for the customer, so if there are any patches or any updates that are critical we work with the customer to identify a suitable time for us to do the system upgrade.

We manage our customers' IT infrastructures. We then bring in vendors according to what each customer requires. We are the system integrator, integrating to their backhand system. We provide consultancy and advice to the customer with regards to the types of products that they should choose. Eventually, we support products once they have deployed them. A lot of customers don't have a big IT team locally to support the infrastructure, so we provide that level of support.

From an implementation and costing-strategy standpoint, I would give Tufin eight out of ten. It would be much better if they could improve the F5 support and also enhance the documentation in terms of integrating firewall products.

We use it for advanced reporting and root analysis. In some cases for clients, we use it for root deployment. 

Some clients wanted to have more latitude with root deployment. Instead of deploying through us every time, they want to deploy a new root, making quick roots or small roots, like adding an object to a root. They now have the possibility to go direct.

It has helped our clients to meet their compliance mandates. They will ask us for evidence that we can provide them.

The analysis is the most valuable feature. People see it first and that is why they want in their enterprises, then they start explore the other features.

It provides a great visibility around the roots: Root implementing which can be done, roots that have changed, and what has been done. So, it's pretty useful when you have an audit going on. 

I would rate their reports as a four out of ten. I don't like the way that they are shown. It is too hard to export and send them to our clients.

We are switching to AlgoSec. It's a corporate decision. There's probably room for improvement. 

It is pretty stable. We have more issues with the VMs than with the software.

We have not had any issues with scalability. When we needed more power, we just added a new server, and that was straightforward. So, it is pretty scalable. 

I have not personally used Tufin's technical support.

The last time that we initialed setup, it was straightforward. 

If you want to install a new root automatically using the tool, the change impact analysis capabilities are useful.

We deployed it in-house. 

This solution helps us to reduce the time it takes to make changes (by 10 to 15 percent).

We are going to keep Tufin as is, but we are going to add AlgoSec. The prices are comparable. We have corporate pricing with AlgoSec. The ease of use of AlgoSec is one of the reasons why we considered using it.

You need a product like this, but look at difference solutions in the market. I would rate it a seven out of ten.

We do not use the product across our entire network. We do not use the cloud native security features.

In the future, we will use the solution to check if a change request will violate any security policy rules.