What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
We are using it on a more regular basis now.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
I don't think we've worked a lot with the technical support teams yet.
Which solution did I use previously and why did I switch?
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.
How was the initial setup?
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.
What about the implementation team?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.