What is our primary use case?
We are using it mostly for reporting, as well as NERC CIP compliance for rule documentation. The primary use case is for doing rule cleanup, knocking down overly permissive rules, and cleaning up old unused rules. Basically, we are using the reporting functionality out of SecureTrack.
How has it helped my organization?
We use Tufin to clean up our firewall policies. We use an automatic policy generator. This is huge for us because certain rules, especially if they're overly permissive rules, have to have an analyst go through log file after log file, which is just impossible. Versus just setting Tufin, letting it run for a couple of weeks, then going back and looking at the results. That has definitely been a big win for us.
The policy comparison reporting has been a definite big improvement for our organization.
We've used it to give read only access to look at actual policies for different departments who might not necessarily need access to the actual firewalls. This has created some efficiencies for us because an engineering team can go in and check to see if they need to engage us for firewall rule changes without having to engage us first, because they have the direct access.
The solution has helped us meet our compliance mandates. We use the policy browser metadata to do documentation for rule justifications. That is what we supply to our external auditors.
What is most valuable?
The most valuable features are the rule set analysis reporting that you can do. We use it day in and day out for doing rule cleanup and policy analysis.
The policy comparison reporting is one of the more basic functions that it has, but it is very critical for us. We built it into our processes that before we push any change to production, an engineer will stage actual date rule changes and policy changes. Another engineer will go in and do a comparison report of the last push policy to the last save, making sure what has been changed is what is expected to. From an operational excellence, it's huge for us. We have huge policies. All it takes is one accidental right click, delete, or backspace button, which could impact our business. So, this is something that we use almost day in and day out.
We're definitely happy with the visibility. It gives us a lot more visibility and can do a lot more reporting that just wouldn't be possible for a human to do, who might just be looking at traditional log files.
What needs improvement?
We had a discussion in the Customer Advisory Board yesterday around use of SecureChange. We would like to have an opportunity for an engineer to choose if you want to make or take the policy which has been suggested by the designer functionality, making it more human readable or less human readable (more or less granular). This would be huge for the customers who are using SecureChange. They said this was one of their issues with it, especially for anything that was going into a regulator's or auditor's hands. The more human readable, the better that it would be, and this would definitely be applicable to our industry. It sounds like they are working on this issue, or they took the feedback, but that would be a big one for us in being able to make the jump to SecureChange.
What do I think about the stability of the solution?
Stability has been rock solid. We were joking about that last night. There was a good amount of time where we weren't running reoccurring backups on a couple of our older appliances. They ran into no problems, whatsoever, for hardware or software for years. So, we were sort of joking, "The product's so good that we don't even have to back ours up half the time." Thus, stability has been very good for us.
What do I think about the scalability of the solution?
Scalability is to be determined at this point for us. Right now, we have five or six isolated instances, and we're going to collapse those down to a single front-end. Then, we'll scale up to how many devices that we're monitoring. At this point, we haven't had any issues with scalability, but we haven't really pushed the appliances too hard yet.
Making sure that you are designing or coming up with a solution and architecture which is scalable and as holistic as possible. We had some discussions yesterday with some other customers, and having the complete visibility of your entire environment rather than just a subset like we do today at our company will make or break your functionality of the product. Being as all inclusive as possible is probably critical, especially if you're looking at things like SecureChange.
How are customer service and technical support?
The few times that we have had to engage tech support, they have been good to work with. They were pretty simple cases in both instances for us.
What was our ROI?
Our engineers are spending less time on manual processes, specifically for the reporting functionality. For doing the rule cleanup and policy analysis, it would be a nightmare to do that manually. So, it is saving our engineering teams time from not having to do manual log reviews.
What other advice do I have?
We are siloed. We have separate areas of responsibility for parts of the network. The pieces of the network that our team manages, and what our Tufin instances are monitoring, is all for the data control system for anything real-time, e.g., the gas and electric control systems. Therefore, we don't have complete visibility of the entire network because we are only monitoring that subset of the network.
We don't use any workflows because we're not using SecureChange.
We haven't used the solution’s cloud-native security features.
Which version of this solution are you currently using?