Tufin Orchestration Suite Reviews

The primary use case is locking down the firewalls to Zero Trust and automating the risk assessments.

We use Tufin to clean up our firewall policies. It very easily shows us what is not used, so we can take it out. It shows us head counts as well, so if something is used once or twice a year, that might not be something we want to keep. Thus, we can have the conversation. We also like how it has a business owner of the firewall policy, so we'll be filling that in. So, those people will be involved ongoing with the approvals.

This solution has helped us meet our compliance mandates by providing visibility into firewall rules.

Today, we can check to see how our lockdowns have gone and what unusuals are still there. We have a long way to go, but we've done a lot already.

We were hit by the NotPetya attack. Therefore, our whole company and all its sites were down for several months. So, you don't have an attack like that and not need something like Tufin. Other companies can prevent these attacks, or at least slow them down, by having this type of a tool. We will never go back.

In the future, we will be using this solution to automatically check if a change request will violate any security policy rules.

1. Being able to see all the firewall rules in one place. 
2. Being able to query them. 
3. SecureChange will automate and put the rules into Remedy.

The visibility is incredible. It has never been there before.

The UI was a little clunky at the first. It was confusing. They are working on that. The new one is better.

We haven't really overburdened it yet. What we have has been very stable. There have been no issues that I have seen.

It seems very scalable.

We have 40 consultants and too many people.

The regular technical people seem okay when you put in a help call, and they do get back to you. We actually had a key issue, which was a bug, that the development team didn't want to fix. We escalated it, then it got fixed. So, the management level seems very responsive at least, but at a support level, they are just regular support people and not outstanding.

I asked our firewall team if they had the tools that they needed to do their job, and they said, "No."

We did not have a previous solution.

The initial setup was pretty straightforward. The problem was getting people to pay attention to it.

It is a lot of work to implement.

We used Tufin for the deployment.

We have not seen ROI yet. What we are going to see is fewer cyberattacks. When you have a multimillion dollar cyberattack, you don't care about three million dollars in a one time cost.

Engineers are spending less time on manual processes by weeks. Huge amounts of time have been saved.

Our licensing costs are three million total and then we pay for maintenance, which is an additional cost for three years.

We did a comparison of three products and Tufin was recommended at the time. We got quotes from Tufin and another product, and Tufin came in under.

I just talked to two people who switched to Tufin from another product. It seems to be the leader of the pack.

Tufin seems like a high quality product from a company that cares. It focuses on exactly what we need.

We would like to get to having Tufin make changes on firewall rules, but we are going to need help convincing our management of that we should be using Tufin to do that. It looks very promising, but we can't use it for that yet.

We haven't implemented the change workflow process yet.

While we didn't buy it for the solution’s cloud-native security features. I'm interested in that, but it is not in my mandate right now.

The product has been fabulous.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Our primary use case for this solution is firewall automation for rule requests.

We use Tufin to clean up our firewall policies, and it has benefited us by reducing our policy set. It has sped up the change request process as an overall whole.

This solution helps to ensure that our security policy is followed across the entire hybrid network. We are able to see both on-prem and cloud, and whether there are things preventing on one side or the other.

The time that we require to makes changes has been reduced from weeks to days.

Our engineers are spending less time on manual processes, with the majority of our tickets being same-day.

The most valuable feature of this solution is the ability to develop it further than what's out of the box.

The visibility is not as good as it should be. There are certain things that it doesn't have visibility to yet, but I'm hoping that it's coming. Once it has greater, fuller visibility, we can do more.

The change workflow process is flexible and customizable to a certain extent. The GUI is limited with respect to how much you can develop and visualize the process. However, there is good flexibility in the number of fields and text that you can add.

SecureTrack needs improvement, and access to SecureChange needs improvement.

Some of the features that I would like to see in the next release of this solution are:

• I would like Tufin to be supported on a container that is based in the cloud.
  
• I would like the database to be separated from the backend.
• I would like better automation support for Palo Alto.

This is a pretty stable solution. I won't say that there are no issues, but it does what they say it's going to do.

I think that the way it is architected, currently, is limited in its scalability. In the future, it should be more scalable.

Technical support for this solution is good. For a lot of the issues we have, we go directly to R&D.

We did not use another solution prior to this one.

The initial setup of this solution seemed to be straightforward until we got into the details. At that point, we found it to be complex. Once you start thinking about the things you want to do and how you want to do them, because it's so customizable, it can become complex quickly. However, not in a bad way.

We used G2 to assist us with our deployment, and they are great to work with. They're easy.

We have seen ROI, but I do not have any data points that I can share.

Our licensing fees are approximately $100,000 USD yearly.

We considered other products, but Tufin came with the best out-of-the-box solution, and with the greatest flexibility to change in the future.

We do not yet use this solution to automatically check if a change request will violate any security policy rules. We have not yet utilized this solution to help with compliance.

With respect to the cloud-native security features, we are not leveraging the cloud as much as we should with Tufin.

There could be better things out-of-the-box; However, I know that it is a solution that has to cover a wide range of industry and supportability, so therefore it's a challenge to get everyone's wants and needs.

My advice to anybody who is implementing this solution is to spend more time than you think you need on SecureTrack because it sets the standard for using SecureChange in all of the other products.

I would rate this solution a seven out of ten.

We use this solution for workflow intake and policy cleanup. It is also used for firewall policy requests.

We make use of the ability to automatically validate changes to security policy rules. For example, we have four workflows currently in SecureChange, and for two of these workflows, the very first thing that we do in response to a policy request is to evaluate it. We check to see if the new policy is needed or not, and we determine how to proceed from there.

The biggest benefit for us is from an efficiency perspective. The longest part of our firewall policy implementation has been verifying the network and finding out where policy needs to be put in place. Tufin takes this job down from a day, to sometimes five minutes.

This solution provides a more organized manner for us to track towards compliance for our PCI audits.

The most valuable feature for us is the topology validation that is part of the workflow.

This visibility that this solution provides is better than that of the competitors that I have looked at.

When this solution works in the way that we need it to, my impressions of the change impact analysis are very good. The hardest thing for us is the inefficiencies with topology. This often means that the results we get are inaccurate.

One feature that is missing is the ability to assign a step in the workflow to a specific user at a specific time, based on how the previous steps of the workflow have been handled.

For the traditional application, SecureChange, my impressions of its cloud mandated security features are not very good. Tufin Iris looks more promising.

We have had issues with the stability of this solution, and the basic technical support is not very good.

In the next release of this solution, I would like to see the normalization of configuration files as they're brought in so that there can be some regular expressions set up to parse them. I would like to see additional cloud support, and the inclusion of security tags as a way of determining risk in the USP.

So far, our impressions of stability are not very good. We have already had to RMA one of our boxes, and it was not being utilized very heavily. We've had different issues on some of our other devices, as well.

Scalability is hard for me to say based on what we have deployed so far. We do have issues, but it's hard for me to say whether they are because of the hardware, or are an issue of scale.

The basic technical support for this solution is not very good. However, the Critical Situation Team is actually very good. I would say that the support experience depends on which group you get put under.

Prior to implementing this solution, the majority of our security engineering's time was spent working with these policy requests. It was a manual process where a requester would submit and Excel sheet, and the changes were being done from there. This was not leaving time for that team to work on projects and initiatives that were furthering or bettering the company. We started looking into Tufin as a way to automate some of that process and free up some of their time.

The initial setup of this solution is very complex. Putting all of the devices into the topology, and then getting it to a place where it can provide meaningful and accurate results, and then building the USP on top of that, are all very complex. Out of the box, I don't think that Tufin really provides very much until you get through a lot of those complexities.

We handled the deployment in-house.

I'm sure that there is ROI with the time savings that we received, or that we get as part of working the secure change workflows, but I couldn't speak to any hard numbers.

The shortlist included both Tufin and AlgoSec. Our evaluation showed that Tufin's features were on par with AlgoSec, but Tufin was the better financial choice.

Prior to using this solution, our SLA for any change that went into production was ten days. We’ve now lowered that down to two days.

For the most part, our engineers are spending less time on manual processes, but this is when the topology works the way it's supposed to. When it isn’t working the way it's supposed to, then they spend more time than they would normally.

My advice to anybody who is implementing this solution is to start small. Pick an area of your network and deploy Tufin, then get it working in a manner that suits your needs. After this, expand it out to the entirety of your network.

This is a good solution but it is not perfect. There is a lot of stuff that is unsupported and it is inefficient.

I would rate this solution a seven out of ten.

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.

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.

Tufin is the product which we do our compliance under. That's one of the requirements. We also do change control tracking: who does what and the impact. 

The users have reports for best practices and clean up.

The primary use case going forward will be automation, changing the internal process by trying to eliminate human errors.

Change management tracking is important: Who does what when. We know if something happens by checking the reports and comparing. We know exactly what mistakes were made and corrections. 

In a financial organization, there are so many approval processes. At the designing levels, you can add any number of layers (for approval/decline), add qualifications, and traffic flow analysis.

Because it is a predefined customized, we can define whatever we want it to be and add the exceptions.

SecureChange makes our lives easier with automation. 

It provides a granular report, like what is there or not and what is required or not in the clean up. This makes our lives operationally easier. 

It is very easy to learn and is user friendly. The GUI is user-friendly.

I'm looking for the backup change. I want a predefined backup plan.

The stability is a pretty standard. It is working, and not like other products where it is breaking the system. It is pretty stable.

We will be using the appliance based product, which cannot be scaled as much. It is a limitation in the hardware.

The technical support is very good and helpful. We have not encountered that many issues in any one place. 

The initial setup was very straightforward because the documentation was straightforward.

We did it ourselves. Tufin support helped us with the configuration.

We are also evaluated Skybox and AlgoSec.

Tufin is meeting one of our requirments, which is why we are looking to the future with the product.

There is room for the product to grow.

Firewall automation and orchestration.

It has allowed us to be more efficient in our processing of firewall requests.

We use this solution to automatically check if a change request will violate any security policy rules. Every change request has to go through a security approval step, but we also leverage the Unified Security Policy to automate some of that decision-making.

Workflows that help continue automation.

The change workflow process is flexible and customizable. Just about every step has some flexibility to it. While there is room for it to improve, it is very flexible to our needs.

The change impact analysis doesn't even get close to actually solving our problems. I am not impressed with it.

The solution's cloud-native security features are lackluster. They need to catch up to where the industry is at.

Our engineers still require quite a bit of manual digging to find the data that they need. It would be nice if the product would allow more flexibility around that and the workflow to present more data to correct this.

There are tons of things that the solution needs. They just need to prioritize them and get some of their customers satisfied.

It's not a very stable product. It doesn't stay up as often as I would like. It crashes at very inopportune times that we just can't afford.

It is not very good. It scales but not eloquently. It is complex and not easy for our organization to stay on top of managing it.

The technical support is okay. It's not the best, but it's not the worst.

Tufin is our first solution of this type.

It was pretty straightforward. It was not too challenging to get it going. This issue is just maintaining it.

We worked with Tufin Professional Services to do some deployment. Most of it was internal, in-house customization and put together.

I have seen ROI with this product.

We've seen a decrease of about 50 percent in the overall time it takes to complete a firewall change.

We chose Tufin because its flexibility at the time was much greater than their competition.

We did not evaluate less costly solutions.

While it has its highlights, it has deep issues that need to be addressed.

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

Our company doesn't really have federal or regulatory compliance requirements.

Spend a lot of time testing and doing a PoC for it, before you make the final decision to go for it.