What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
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.
How was the initial setup?
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.
What about the implementation team?
Tufin's team helped us mainly with the Check Point stuff when we ran into some problems.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.