Tufin Orchestration Suite Reviews

The primary use case is for compliance with PCI regulation for local and country regulations.

We are using the latest version of the product.

We use Tufin to clean up our firewall policies because it is so fast. A report about compliance and the clean-up process used to take about one month up before. With Tufin, it takes only one day.

Implementing roles in the firewall used to take two days, but now, it takes two hours.

The audit and policy relation reports have helped me show compliance to managers.

The product helps my cybersecurity team. Now, my cybersecurity team spends their time creating new controls for new technologies.

The workflow is the most valuable feature.

The visibility that the solution provides is amazing.

The change workflow process is flexible and customizable. I can send one request to an IT Manager and another one to a Development Manager, making them customized.

I would like to see more about the cloud in the next release. They need a large plan to deploy the cloud into the solution and a way to implement it.

The web service for integration with other solutions needs improvement.

The stability is okay.

At this moment, it is not necessary to expand the solution.

I don't really use the technical support.

We did not have a previous solution. I was looking for a solution to optimize time in security policy management. Then, I found the Tufin and contacted a reseller.

The initial setup was super easy. It was fast to implement the firewall. The Check Point was very fast.

We used a reseller for the implementation. It was the first time for the reseller to do this implementation.

It saves us a lot of time. People can devote their time to other more important tasks. 

The seller of Tufin, when I wanted the solution, was very flexible because the cost on the lease was very high in Latin America. So, he was able to reduce the cost.

We considered Algosec and Firemon, but Tufin was the best.

A powerful tool for a security team to optimize time.

The primary use case of Tufin is firewall management, firewall reviews, and eventually, to do rule deployment.

It was more to start standardizing our prior work changes. The initial first step is to understand and make sure that whatever change goes in is complying to our policies and standardized. The eventual goal is to get everything automated.

We are using SecureTrack at the moment, but we do have licenses for SecureChange as well.

We use this product to sharpen our change cycle. A request used to take quite a while as we did manual assessments. A lot of that is now done through SecureTrack. 

At this stage, we are doing only manual checks. We are only using SecureTrack to verify the flows through Tufin. At a later stage, when we will also automate certain types of rules to be done through SecureChange, this will tremendously help us. We are not there yet, but this will help us in terms of time and resource costs.

In the past, we would do certain things because of private knowledge of people's own understanding of the network. We don't have to rely on just that piece of it, because of the topology. We now know which firewalls come into play. 

We use Tufin to help us clean up the firewall policies. It provides very easy reporting. We get all the aged or unused rules listed very quickly, as soon we run the report. It's a quite easy way of doing it. However, we have not automated our process. We are hoping that at some point that we will be in a position to automate that process.

We use the solution to automatically check if a change request will violate any security policy rules. If a request comes in, and it is from an Internet zone going straight out to an inside secure zone, then we definitely flag it. There are other policies that we find in our USP, which we flag. These are the type of things that we check.

We definitely use the compliance reports, which has simplified things. However, we haven't fully integrated it into the GRC process with Tufin yet. The desire is to make sure our GRC resources are fully aware and engaged in our Tufin deployment.

We are leveraging some components to provide reports for our GRC process, but there is no plan to integrate those processes. Those are run by different teams. We were planning to integrate our ticketing system (ServiceNow) with Tufin, which is ongoing. We are working on that now.

The central repository of information provides a consistent way of doing things, eventually shortening the time period to make changes. This is the most valuable thing at this point in time. 

I'm very happy with the visibility component. It gives us a reasonable insight into the most of the application flows. Obviously, most east-west application flows are missing from what we have. That is a component which we will need to eventually fill in the gaps.

Between the cloud and physical data centers, we definitely share Tufin policies. That definitely gives us visibility into both.

I would like to drive value from is to getting to a point where we are almost like a DevOps operation for security changes.

We have put in a lot of requests. Some of them are high level related to cloud. Others relate to some of the reporting structures that we have. E.g., some of the automated reporting capabilities for specifics on certain regulations. Certain countries have certain regulations, and with GRC, if we can associate that on certain regulations, then we can spit out reports from that.

We would like to see integration of the different versions of this product, e.g., SecureChange and SecureTrack. They eventually need to start amalgamating all these into an end-to-end product for visibility. 

We do have an ongoing issue with capacity. If one of our resources is working on it, nobody else can do anything. If a particular report is being run on the server, nothing else seems to work. We haven't done anything about it as of yet. Maybe some of my team members have opened tickets to Tufin for it.

I am not sure about the scalability. The product that we have deployed for our main process gets bogged down in terms of its response. Maybe, we need to deploy a slightly smaller box. Eventually, we need to discuss this with Tufin is to see if we can move over to some sort of VM environment where we can add more processing power to it. 

We have a global implementation.

Whenever we have had a problem, some of my engineers contact Tufin and they have been very easy to get a hold of. From my team, they have not had any problems with the technical support.

We were using Tufin before, as well, but it was not the same. It was separated into localized instances and regions.

We sort of saw that the volume of changes were coming in high. The patience from the business side was getting low to invest the time that it used to take to make firewall changes. Therefore, it was inevitable that we need to purchase a solution.

Our initial setup was complex from two dimensions, because we were deploying it globally and had to have a centralized view, but a distributed approach. We had it in Asia and North America (US and Canada), causing a slightly complicated approach.  Prior to Tufin, we had three instances which were separately managed, so we did not have end-to-end visibility. Therefore, we rearchitected the Tufin environment and created one global Tufin instance. The retail instances became local collectors, which reported back to the single environment.

From the start of the project to the end of the project, the deployment took us a while, at least five to six months. Most of the time involved was not because of Tufin. It was primarily for us to handle all of our separate service providers and outsourcers globally, so they could all provide us with read-only access to the firewalls that they manage.

We deployed the solution in-house. It was pretty straightforward to deploy.

The solution has helped us reduce the time it takes us to make changes from weeks to days.

Engineers are spending less time on manual processes by about 15 to 20 percent. I would like to get a bigger number.

We didn't buy this based on ROI, so we didn't measure ROI. Overall, from a time savings perspective though, it is definitely there.

The licensing costs are around $250,000 to $300,000.

There are ways to deploy the license to different types of firewall. However, if we decide to change the physical brand of the firewall, we need to go back to Tufin and modify the licensing. This is a hassle.

We did not consider anyone else, because we already had an unused, unimplemented Tufin license. We eventually thought to start consolidating everything into one place.

We decided on Tufin because:

• It was an existing tool.
• It served our purposes. It provided us the essential components for managing a varied environment of different types of firewalls. 
  
• We felt that there was enough potential in the organization to grow with us and provide capabilities, like cloud, VM environments, etc., under the same umbrella.

It gives us visibility and the ability to make changes automatically with less mistakes. Overall, it's a decent product.

Tufin is definitely a good contender to come as a winner. It has the potential to look not only at firewalls, but also network devices and other cloud-native solutions. It is a pretty broad base product, which will eventually be a good future tool to have in a toolkit.

We haven't used the workflow from Tufin. We use our own ticketing system for that. We are busy integrating our ticketing system with Tufin right now using an API. We are just in the process of doing that.

Tufin helps us understand and ensure that security is being applied. Tufin is not a security tool. It just gives us all the information about security, firewalls, etc., and that they are doing their work. From that perspective, it would be a long stretch to say that Tufin provides us security. However, Tufin provides us the information that we have security across hybrid environments.

All of our cloud-native security features are directly taken from cloud management tools. We don't have anything deployed yet from Tufin for cloud-native security features, but there is a desire for that.

The primary use case is monitoring routers, switches, firewalls, but mostly routers and firewalls.

We are just using SecureTrack, either version 18-2 or 18.3.

We use it to aid with firewall reviews. We don't have SecureChange active, but we can take the info and use it to help. We have found a lot to work with.

Tufin has been helpful with making sure all parts of our organization are following change management:

• If you are changing rules, then you have tickets, and there is the approval process associated with it.
• Seeing people are sticking with those temp rules, if they end up staying there for awhile. 
• Sometimes, there are just bad rules where something that should've been "deny" and should not be allowed.

Those are more direct examples without getting too far into the weeds.

It is greatly aided in helping us meet our compliance mandates. There used to be manual reviews for certain compliance requirements. Now, this solution helps automate a lot of that, and even the parts which are still manual. It's a lot more comprehensive than trying to read raw text files of the configs and making sense of those.

The solution helps us ensure that security policy is followed across our entire hybrid network. It is like a centralized single pane of glass where comprehensively shows things, especially coupled with the Network Topology piece that they have. You can say, "Here's where the DMZ is, and here's that. These are the amount of firewalls crosses this through." Whereas before, it was this big spreadsheet of all the firewalls and zones. Except for like two or three legacy knowledge people, no one really understood how it flowed before Tufin.

It has helped us troubleshoot, e.g., why isn't this still working? "Oh, they put it on the wrong firewall or they typoed it." The solution has helped with that.

The firewall reviews for compliance used to be a more labor intensive process. It used to take a few months, and now, it's down to just a couple of weeks.

It provides a comprehensive overview of what our network looks like in terms of what is allowed and what is not, then how the traffic' is flowing with the Network Topology Map.

With the Unified Security Policy, the more you improve it, the more you will get out of it.

For the things that Tufin is able to work with, it is really great. It sort of provides a comprehensive view. It is easier to explain to people who don't really work with firewalls everyday:

• Why this is an issue.
• Why certain things are an issue.
• Why some things are the way they are.

I wish they had a credentials vault or something. Right now, you have to manually add a username and password per device, and if they are using something like in a centralized, like an AD account, that password rotates eventually. Now, I have to go back and change information for all these hundreds of devices. Whereas, if they just had some credentials vault for credential one, two, and three, then you could just reference them per device and change it in one place. It would make our lives a lot easier.

I wish there was a read-only admin option. I don't like that you have to be a full admin just to see the Network Topology Map. That option is great out there if you are a user, multi-domain user, etc. However, that piece is very helpful for us, but I also don't want to be handing out admin access to every single person so they can see that network tab. 

Tufin covers a lot of vendors, but there are still some that they don't, like Radware. Some of these vendors that they don't cover are at critical points in our company, as far as explaining the full picture of our routing. Since it can't show the full picture, it can't support that. 

The stability is pretty good. We have run into repeat issues with Palo Alto Panorama, where it doesn't seem to play nice if we change the vice group names in Palo Alto or if one of the Palo Alto servers is down, but it is in Panorama, because we're pulling everything through Panorama. Sometimes, it'll freak out and cause everything else to stay and be unable to get configed. Then, our Palo Alto products will sort of cease, usually a good majority of them, which is not ideal.

So far, scalability has been doing well. 

The technical support is very good. They respond pretty fast. They are always available whenever I need it. It is usually my fault when there are delays because I just don't respond to an email. I forget, then a few days go by and email again like, "Oh, shoot." The technical support has always been on top of things.

Someone before me had stood up the actual server on the network. They had one device, and it was monitoring. Then, I took it over. I've expanded it out to over 400 devices.

They made getting new monitoring devices in pretty easy. From the monitoring devices tab, it was pretty straightforward. You pick the vendor, then under there, this is a drop-down. I struggled a bit under the Cisco tab where they have a router, then a Nexus router. They have a lot of different vendors, and figuring out which category it falls under was confusing. The help docs don't exactly specify between the two or what commands it will be running. This is usually more for our older devices. 

We had Professional Services hours. However, as far as getting the actual devices and scaling it out, that was all just me.

Understand your DNS or network segment. What all these different subments and how they will fit into what categories, because you are going to directly take that info when you build out your USP. If it's too messy, your USP is not really going to do anything. You need to have a good dictionary for the USP to follow.

We aren't really using the cloud-native security features in our current environment.

Our primary use case is firewall automation. We use SecureTrack and SecureChange. We have distribution serves, Remote Collectors, but what we primarily use is SecureChange integrated with ServiceNow for users to submit firewall requests. They then go to SecureChange which designs the rules and implements them.

When it comes to the turnaround of firewall rule requests, it used to take about a week to implement and have the customer test for firewall access. Now, it can take just one day. The implementation itself takes a minute or two. For the customer, it may take the rest of the day, by the time that the policy is installed and the customer tests, either that evening or the next day.

While I'm not involved in the leadership, I believe the solution has helped us to meet our compliance mandates: from a firewall perspective, as well as an audit perspective, as well as review of the rules and source and destination port requests.

As for ensuring that security policy is followed across the entire hybrid network, we're getting there. That's part of why we implemented Tufin. We are implementing that across our multiple offices. Once we get to that state, it will ensure that security policy is followed.

Finally, using the solution, our engineers are spending less time on manual processors.

In general, the automation piece is the most valuable feature: having SecureChange make the change on the firewalls, instead of my having to go manually make the changes on the vendor product.

In terms of cleanup of our firewall policies, we don't officially use Tufin, but I, as an architect, do use the Automatic Policy Generator to review existing rules: high hit-count rules and open rules which aren't very secure. We use that to then build firewall rules which tighten up our firewall policy.

The change workflow process is flexible and customizable. We have had to edit and alter some of our workflow and it's pretty easy, pretty simple, pretty straightforward. We use Tufin support, their helpdesk, for that because we're a very new customer.

In terms of the visibility the solution provides, we have hits and misses with it. Overall, we think it works. We would like to get more automated, but that could be an issue internally with services and ports that we allow between different zones and our USP matrix. We're working with Tufin representatives to help solidify that and clean that up a little bit. That's one of the headaches and hiccups that we have right now: the full automation piece. We have automation to an extent, but we still have requesters who submit requests that still require approval, whether it be firewall leadership approval or cyber leadership approval. We want to determine what ports are allowed between the zones, as I mentioned, so that we can have full automation and there's no human interaction at all.

We would like to see automation metrics, from a reporting standpoint. We would also like to see automation of site-to-site VPN tunnels. We would like to see automation of Check Point application-based firewall rules. That's available on the Palo Alto side, but we are primarily a Check Point site on-prem. We have Palo Alto on the cloud but most of our on-prem stuff is from Check Point, so we're waiting for that. Those are some of the key things we're waiting for.

My impression of the stability is positive. We haven't had any issues. We even went through an upgrade about a month ago and it was a smooth process.

As for scalability, we're finding that out right now. We're building out two new Remote Collectors for our global deployment of an additional 150 to 180 firewalls, plus additional Layer 3 appliances. We're working through that right now. Hopefully, it will be a smooth transition but I can't say for sure because we haven't actually implemented it yet.

I would rate tech support as "fair." Response time is a little slow, but when they do respond, and when time is available for them, we work through things pretty quickly to resolution.

I wasn't involved in the initial setup, but from what I've heard from others from whom I took it over, it was very straightforward.

I know they reviewed other solutions but I don't know which, for sure, since I inherited the project. I would assume AlgoSec and FireMon were reviewed as well.

Be as detailed as you can within your introductory meetings, and your planning and implementation phases, because if you don't mention something and it comes back later, you're going to have to work through it. That could take time, it could take extra money. You want to make sure, upfront, that you know everything you want to do so that it's all included in the cost for the Professional Services implementation.

We do use it on the cloud; we're having some trouble right now defining the network policy on our cloud. We're working through that; it's part of being a new client.

I would rate Tufin a seven out of ten. We're a very large, complex organization, so we're still working through some stuff that we focus on, things that, perhaps, other customers don't, or that Tufin doesn't have integrated in the TOS software.

The primary use case is role recertification.

We are trying to get into it for compliance, but we are having issues with that.

This solution helps us ensure that security policy is followed across our entire hybrid network.

We actually review our firewalls now. Before we started using Tufin, our firewalls never got reviewed and we had no idea what was on them.

We use Tufin to clean up our firewall policies. This makes it a lot easier to find out the things that are wrong.

It removes things which shouldn't be there. It has helped with that. Things that don't get used anymore and nobody tells us that they have been retired, it helps us identify those items. Then, once we get the compliance piece going, it'll help us make sure nothing violates policies.

The most valuable feature are role and objects usage for individual objects and app usage.

If we could get the compliance part working, that would help out a lot.

Currently, we have to get different data from different sections of the site. It would be nice if it was all combined into one.

A big improvement would be on the USP policy. If we could use Palo Alto to take those zone names and auto import them into the policy, then just do the policy based on the zone names instead of having to put in every single subnet.

The user interface needs to be redesigned because things are not where you would expect them to be.

Stability is sometimes good, and sometimes not so good. 

There is an issue with all of our Palo Alto devices, where if one gets disconnected in Panorama, they all show as disconnected or with errors or wrong arguments, which is very generic. They are supposed to have a fix for it now, but we haven't implemented it yet, because they are not releasing it until eleventh of this month.

We haven't had any issues with scalability yet. We can scale as much as we need to.

The technical support is good. The guy with whom we have been working the most with lately has been pretty on top of everything. We had a couple people in the past who were a little iffy, but we haven't had to talk with them in a long time. I don't know if they're still there.

Our licensing costs are pretty low. We were grandfathered in, so we are at about $35,000 per year.

Test every feature. Make sure the third party vendors that they implement into it function properly with it. We have had issues with our Palo Alto connections.

We just started a PoC on the change workflow process of the solution.

We are just now moving stuff to the cloud.

We do risk, cleanup, and change.

It reduces human error and speeds up the whole change process.

The change workflow process is flexible and customizable. There are five default workflow processes out-of-the-box. However, every customer is different. Everybody has a different request process. That is why it's so customizable. You can add another step, you can delete a step, or you could put in an exception. It is very flexible.

We use this solution to automatically check if a change request will violate any security policy rules. E.g., we will not be allowing SSH to the Internet. That is one change request where we can be like, "Put that right on top of the policy." 

This solution has helped us to meet our compliance mandates, especially with the default out-of-the-box templates, then you can create your own.

This solution helps us ensure that security policy is followed across our entire hybrid network. You can have a Unified Security Policy which reaches across all networks, so if you are having a change submitted, it doesn't matter if you're enforcing it or not. You can get an alert saying, "This is a violation." That's a value-add.

• Cleanup
• Visibility
• Scalability
  

Cleanup is its most valuable feature. We use Tufin to cleanup our firewall policies. You can see unnecessary, unused objects. A lot of times, you will create a host, then it's not used. It's like, "Delete that, because we don't need that in the database." Or, it's a rule that is not needed: unused rules.

Its cloud-native security features are good. They add even more visibility to your environment.

I would like more out-of-the-box workflows in SecureChange with more default config, so you don't have to create those workflows yourself. This would be the biggest thing.

I would also like more enforcement. Right now. it's a lot of alerting. You see it in Tufin, but you have to go to Check Point or whatever device to make the actual action.

We already know the user interface is getting redesigned in TOS 2.0. That's naturally been the customer complaint in my experience, "Where are things in the GUI? The GUI is cumbersome." Now, I'm used to it, but when your first learning it, it is unintuitive.

The stability is very good, especially now that they are developing a lighter weight operating system on top of the OS with 2.0 coming out this year. 

The current version is slow. I deal with a lot of large environments, which is mostly what Tufin has. It is slow because it is a database, Tomcat Server, and web server. Reports are slow. If you're generating manually on the fly, you can set them to run at night, then it's not a big deal.

The scalability is good, because you can have a central server, distributed server, and remote collectors. You can have remote land sites or branch offices. You can have the collectors collect the data for you. You don't have to rely on just one server.

The technical support is very good. It is a lot better than the firewall vendors themselves.

There were not enough resources to do the changes themselves. We definitely went offshoring. Now, you see a lot of that coming back because there is not enough people. We needed a system to do it.

At first, the initial setup is complex. Once you know it, the initial setup is straightforward.

First, you have to install the operating system. Then, you have to install the application, where there are certain version requirements. You can't just go right to the latest OS version. You have to go back to the older one, then upgrade those as well. It is a little cumbersome.

I am an integrator. Sometimes, we have to use Tufin on the back-end.

We have seen ROI just in the time savings and knowledge. Knowledge is power. Having the solution do it automatically for you without you doing the work is huge. If you are spending $50,000 a year, it could have cost you a $100,000 in man-hours without it, especially if you are working with a team..

This solution has helped reduce the time it takes our customers to make changes by 50 percent.

Engineers are spending less time on manual processes by 50 percent.

While licensing varies greatly, it is about $50,000 a year.

We did consider other vendors, but Tufin is the market leader. We only deal with the best of breed. We like to go with the best.

Do a proof of concept or proof of value. You will see the value right there.

The visibility is top-notch. I know the vendors as well, like Check Point and the firewall product underneath it. I know with Check Point, specifically, and I have seen some issues with it. However, overall, there is still a lot of value in the cleanup.

The primary use case is processing change requests.

While our organization has implemented SecureChange and SecureTrack, we are not using either tool rather extensively. Therefore, we are trying to put together a plan for the organization to adopt these tools more firmly.

The idea is to be using SecureChange as the primary portal for entering change requests on both the perimeter and shop floor network firewalls. The way we are approaching this is to do a pilot first among a few sites, then bringing it out to a larger group once we feel more comfortable with how the pilot went.

The pilot will probably last for a couple weeks. After that, we will roll it out in buckets or groups to the rest of the sites. Then, the primary use case will be using tool for change management and SecureChange, while SecureTrack will be used by our security monitoring group who is tracking for threats.

My engagement to date and going forward will be to assist in the planning of the rollout and helping with the rollout. I make sure teams and users who will be using this tool are actually using it, including processes from: 

• Submitting a firewall change request.
• Price or rule requests.
• Opening a port.
• Firewall maintenance or maintenance processes, e.g., rule cleanup.

The additional visibility into network path analysis is really helpful. The ability to provide assistance with role clean up will be helpful as well.

Part of the work that one of our firewall implementation teams is doing is a justification process right now. I think that a clean up is included as part of that effort.

One of the things that we really like is the ability to customize work flow. It seems like there are ways to make a workflow robust and capture multiple different types of things that you would want to do when you are maintaining a set of shop floor network firewall rules. These include things decommissioning a server and performing a common rule maintenance process, like a recertification process. 

The linkage between SecureTrack and SecureChange is nice. The way that you can identify a rule in SecureTrack that needs to be recertified, then create a ticket in SecureChange, which can essentially implement that, and complete the recertification process for workflow. This helps us keep organized, in a big way, a complex, large set of network firewall rules. Otherwise, there is no way for us to track who the business approver or owner is for each of those rules and when the last time each of the rules was looked at. In terms of keeping this set of rules clean, it goes a long way in helping with that.

I had been impressed with the depth of capabilities within SecureTrack, particularly, in terms of generating insights for a user and firewall operator. With SecureTrack, I've been impressed with the level of flexibility with workflow design and its ability to generate different work streams and flows through the tool that are customized for our organization processes.

One of the things that came up this week was the ability to decommission a server, which we thought was interesting. We had a workshop recently that talked about all the things that need to be thought about when managing firewalls. People said, "A lot of times, things get forgotten when you are decommissioning a server." E.g., making sure rules are taken away and taking out the rule set. The fact that there is an automated workload for that can be helpful.

From the training that I've done at the conference, I like the ability to visualize the network paths between different endpoints and servers. I thought that was cool.

I have been impressed with the range of capabilities. The ability to connect with other services and software solutions via APIs is very impressive. In terms of breadth of market coverage, that seems pretty robust.

I would like a USP that was a little like an interface and a bit more intuitive. It seems like the 2.0 version did that better. 

I know when I was performing a search, like in the policy query area, some of those options as your typing could be better defined. That was one thing that came up. I would like it if there was some way to provide real-time feedback or context for each option as you are typing in search fields and search parameters.

Even somebody with relatively little experience like I have should be able to come in and have more intuition towards how to operate the solution. That would be a bit more helpful. There are things that could be explained a little better for somebody brand new to this system, which could be helpful, especially if it was in real-time while you were working in the system. Having the ability in real-time to be able to understand search query suggestions would be helpful.

A limitation right now for compressed firewalls is the limited ability to see above a site level in terms of the Topology Mapping in the policy display. While Tufin's actively working on a solution, or at least they have this in the queue, from being able to view this on a higher level and how all of our site networks are connected, this ability would be useful, as we expect to have these compressed firewalls in place for quite some time.

The Tufin products seem very long-term oriented. The ability to be customized seems good. It seems like there is a good roadmap for what features need to be added.

We did a USP upload earlier this week into SecureTrack, and the upload process was okay. Some of the definitions around the columns and the formatting could be more clearly defined.

The scalability seems good. It is overwhelming to think about how to define a USP potentially for the amount of networks that we have for shop floor firewalls. However, in terms of scalability, it seems like once the information is in there, it can operate well and help speed up change requests.

I don't think we've worked a lot with the technical support teams yet.

It was clear that no one was managing the shop floor network firewalls. 

Right now, there are no tools to do that. As we are hardening and locking down firewalls, the requirement to maintain and manage them becomes increasingly more challenging.

I don't think there was any tool before Tufin. The rules were historically stored in CSM and operated out of CSM. Before that, there wasn't any other way to perform a regular analysis and maintenance of firewall rules in this way from a security and policy perspective.

The initial setup seemed like it required a lot of effort. I wasn't super close to the project during the initial setup. Now that I've gone through the training it seems a little less overwhelming.

For the initial setup, I was only involved slightly on the SecureChange side. The API integration process with BMC Remedy seems difficult. I don't know if that is a result of the way the SecureChange application is designed, or if it's a result of a challenging resource environment for focusing on the implementation and the integration of it with Remedy. But, it seems like a challenging effort.

We used WTT for the deployment. My coworker, Dorothy, had a good experience with them. They were engaged before I joined the project.

The rollout was accomplished largely with an in-house team. The vendor that we purchased it through provided a little bit of support, but very minimal. Then, there is the team who is doing implementation with a lot of the firewall rule changes. Booz Allen has been helping a lot with the rollout, as well. I have been helping to design the rollout and adoption.

For our current implementation, which is temporary, once we move the cleanup process from this implementation team to the permanent team that is when I will be performing the work. That is when I'll be a bit more involved.

The company a good comparison of the different tools. I don't know if they were working with Booz Allen at the time, but Booz Allen seems to feel pretty strongly about the quality of Tufin and their user experience. It does seem like Tufin has reputation regarding its user interface that it is more friendly than other competitors.

I am aware of two other competitors who were possibly considered.

There is a plan for clean up as part of our regular process. There is a process drafted and an intention to do that.

It seems flexible and customizable. The bigger question is whether it will integrate into our existing process effort for change management. There is an existing risk assessment process that sort of fits up into our Remedy change request process, so now we have to think about how does the Tufin change management portal and SecureChange fit into that as well.

Once the USP is defined and we feel comfortable with that, we plan to use the solution to automatically check if a change request will violate any security policy. However, we are not doing that yet.

The program that I am supporting is not engaged in any of the firewalls affecting the cloud, so I didn't have a lot of context with that.

Once we have it up and running, this solution should help reduce the time that it takes to make changes and our engineers should spend less time on manual processes.

I did training at Tufin two weeks ago.

My company primarily uses this solution for reporting and enforcing policy. My role has to do with developing applications to allow integration with our other tools.

When I was using Tufin for analysis, there was a tool that would tell me which rules could be consolidated. It was amazing and helped me to clean up the firewall policies.

We use this solution to automatically check to see if change requests will violate any security policy rules, but I do not have any specific details or examples.

Tufin is the only multi-vendor firewall tool that is available, and it helps to bring everything together and report on what all of the rules are.

This solution helps to ensure that security policy is followed across the network because it is the main tool that non-technical security people use to keep track of firewall rules. Without it, they wouldn't even know where to begin. 

In my current role, the most valuable features are the API and the accessing. In my previous job, the analysis was my favorite.

I would like to see API access into every aspect of Tufin. For example, every feature and everything that's in the database, I would like to have programmatic access to. This would give me the ability to do anything that the product can do but from a script. This way, we are not beholden to the GUI in any way. If an operation requires that somebody click somewhere into the interface, manually, especially if it's just part of many other things that they have to do, then we want to fully automate that.

Some of the manual processes are taking longer because, without the proper API access, there are a lot of tickets coming in. These are from people who need to perform a task, but only a handful of them have access to it. This is because we're too afraid to give access to all of the people who actually need it.

In every instance that I've ever worked with it, it was stable.

I have not dealt with technical support.

In my previous company, I handled the deployment of this solution myself.

Turning on certain options in the solution comes at an additional cost.

My advice for anybody who is researching this solution is that if they are a larger company with a lot of money to spend, and they have a heterogeneous network with more than three different firewall vendors, then they absolutely need it. There is no competitor or really anybody who is even close.

For what this product does, it does well. There are, however, things that are missing.

Overall, I would rate this solution a seven out of ten.