Plixer Scrutinizer Review

Our fault-finding has improved significantly because we can now look through historical data


What is our primary use case?

The primary use case is to track utilization flows for security and for scalability. We use it to see network usage.

How has it helped my organization?

It has improved our fault-finding by at least 50 percent, and as much as 60 to 70 percent in day-to-day networking because we can now look through historical data. When a user contacts us and says, "I'm having this issue," we can review that person's historical data and see what the device is doing, what the issues are, and where the issues might be. In terms of security, our fault-finding has improved 100 percent because we've now got a total view of what the network is doing, right down to a low level. We can set alerts based on traffic behaviors that we know, and track the behaviors that we detect. The alerts tell us exactly what's going on. That is something we just couldn't do that before.

The context base will then allow us then to take it further, from just the device to the user; who was logged in on that machine. The context base allows us to detect who was using it. And even if they move machines, we will be able to see that movement.

The solution has definitely helped to reduce the time to resolution for network and security events by at least half and by as much as about 70 percent. We've now got all the information that we need.

The workflow helps us in terms of security. We've got Cisco ISE which provides endpoint data, and the Scrutinizer provides traffic data on the endpoints. That integration has helped tremendously because we now have two stacks of data. One tells us where the endpoint is, how it was authenticated on our network, and the other, from Scrutinizer, tells us what it was doing on the network. So that integration workflow has helped us tremendously in identifying what network activity is happening, and where it's happening.

What is most valuable?

The most valuable features of the solution are the ability to track what a device is doing and to go back historically. It is also able to go down to, and identify, very low levels of traffic. It gives us 100 percent reporting on network activity.

It's valuable in two cases. It assists in network issues and it helps the security of the infrastructure, so that we can see what would normally be innocuous levels of traffic. If people are "tapping on doors" with very low levels of traffic, trying to do scans and the like — we can detect and identify that. We can then set up the scene to alert us when that happens and that's very useful. That is something that we would normally miss.

Scrutinizer also very much helps enrich the data context of network traffic. It can integrate with Active Directory and with other security products like Cisco Identity Services Engine. We can get context-based information from those sources. So we've not only got the traffic levels, but now we've got the context from which those sources are taken. That's very useful.

The insight the solution provides as a result of its correlation of traffic flows and metadata means I can tell you who's doing what at any time.

What needs improvement?

One of the areas that needs to be looked at is how the databases are created and managed, because they are collecting a massive amount of data. It's a big-data model.

The reporting structure, the front-end GUI, also needs some work. It needs some getting used to. It works fairly well, but it's a technical tool rather than a user tool. You have to understand the structure of the databases before you can really use it. Work is needed on how the front-end user-tool accesses the data and what decisions it makes in terms of accessing that data to get you the response that you need.

For how long have I used the solution?

I have used the solution for about five years.

What do I think about the stability of the solution?

It's very stable. We have not had a problem with it.

What do I think about the scalability of the solution?

We have a rather large network and it can cope. So it is scalable. We're running somewhere in the region of about 40,000 active devices, which is rather a lot.

We don't have plans to increase usage. That would depend very much on the university rather than me. I'm happy that the current implementation of Scrutinizer will take what we have right now. We may have to go to a multi-deployment model if we increase our usage dramatically, but within the scope of the next five years I think we'll be fine.

How are customer service and technical support?

Technical support is very good, very honorable, and very helpful.

Which solution did I use previously and why did I switch?

The vendor's years of experience in delivering security and network visibility influenced our decision to go with Scrutinizer. Up until recently, up until Cisco bought StealthWatch, Scrutinizer was the NetFlow product for Cisco. They've really got a lot of experience in terms of looking at these things, and the chats reflect that, because you've got all sorts of people writing in and telling you how to do things.

How was the initial setup?

The initial setup was very straightforward. There's a script that creates the Scrutinizer. It creates the network management tool. They have what you would call it a Wiki page, a set of enthusiasts, which tells you exactly how to configure each of the different types of devices to report to Scrutinizer. All you do is create the application, set up each of your devices to report to Scrutinizer, and then you sit back and wait for the data to flow in. The analysis tool then analyzes that data as it comes in.

Deployment time depends on how many end devices there are. In terms of building up the management station, I can do that in half-an-hour. It takes a couple of minutes to add the relevant config lines to each end station.

The implementation strategy was to get information from the core and distribution devices. That covers pretty much all of the traffic associated with our network. All our core and distribution devices are reporting on the traffic they see and then we analyze that data as it comes in.

What was our ROI?

ROI, for us, is a much better, much faster resolution to security and network incidents, and the ability to make assessments on traffic utilization. For the SIEM, it cuts down our time by half. It's a valuable tool.

Which other solutions did I evaluate?

We had a look at SolarWinds. The issue with SolarWinds is that it's a statistical model, so it doesn't capture everything, it captures a subset. We dismissed it on that basis. 

We've recently had a look at the Cisco StealthWatch solution but I believe it's a statistical model as well. I need to have a closer look into it. It's fine, but it's about averages. We need a model that captures everything, and that's what Scrutinizer does.

Scrutinizer is better than SolarWinds in terms of functionality. The new Cisco NetFlow product looks to provide — I wouldn't say better functionality — but a better set of graphs, a better user interface. They recently bought a company that provides a better user interface. It's not that you can't do that with Scrutinizer, it's just that it comes out-of-the-box with StealthWatch. But StealthWatch provides it on statistical data, which means that they miss stuff, and it doesn't have a SIEM. Scrutinizer has a SIEM.

What other advice do I have?

If you have a large network then this product is totally invaluable. If you have a large network, this product will tell you exactly what's going on in it. It's not just flows, and this amount of traffic is going out on the internet, but who's doing what on your internet pipes. It will help you. It will cut your incident times in half.

The biggest lesson we have learned from using Scrutinizer is "more data." A lot of data is good. There are tools that can help you. You need to spend some money, but there are tools that can help you.

In terms of eliminating data silos, Scrutinizer does and it doesn't. It creates its own data silo, but the ecosystem approach to the solution helps because now we've got a silo of data that can talk to the likes of SolarWinds, so it doesn't need to keep its own NetFlow data. So it does help.

We haven't used it for SD-WAN visibility yet because we haven't implemented SD-WAN. It's something we're doing at the moment. But I would expect that to be part of that solution.

The solution is largely confined to the network and security teams at the moment, which consist of about 20 to 25 people. We haven't made it available to the end-user support teams yet. That is something that we're thinking about. For deployment, only one person is needed and it's the same for maintenance, from the networking side.

Which deployment model are you using for this solution?

On-premises

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.

Add a Comment
Guest