Plixer Scrutinizer Reviews

We mostly use it to monitor the network bandwidth utilization on various links.

The solution has helped eliminate data silos for us because now, instead of looking at one or two different places, we can look at it all at once. It aggregates the data so it's not in silos anymore.

Scrutinizer has helped to reduce the time to resolution for network events. We are able to identify a problem and resolve it quickly, within about ten minutes, once the issue has been raised. Before, we had to do more work to get there, about a half-an-hour to 40 minutes. 

In general, there are multiple valuable features, but the ability to view the status of the top-10 at a glance is helpful. We immediately know which link is over-utilized or heavily used. We watch the traffic on different network links. For example, we can see what's going on in New York, how much of the network traffic is on New York links and how much of it is in different cities, wherever our customer has offices. That's a good feature, and it's all in real-time.

We can also run reports. We can generate reports for specific links and look at the historical data.

I would like to see a better user interface for creating what they call maps. The solution creates a visual map of a particular location and how the network flows. You need to spend time to generate all those maps. If they could figure out a way to reduce the time needed to generate the maps, that would be great.

I have been using Scrutinizer for four years.

The stability is pretty good. We like it.

It's scalable. They're coming up with a new way of scaling up. Ours is an appliance but I believe their VM products may be scalable. As far as we are concerned, all we need to do is increase the storage, which we can do by replacing a hard disk.

We are collecting data and the network traffic from almost 70 offices throughout the U.S. If everything goes well and we have the opportunity, we will probably try to increase the Scrutinizer footprint. But right now we're okay with what we have.

Technical support is good. If we open a ticket they call back and we work together to solve issues. They are very responsive. I have no complaints.

Before Scrutinizer, we had to do a lot of things manually. It took more time. But now, with this appliance, we have a more automated way of doing things.

This is an appliance. It's pretty straightforward. It came already implemented and installed. Our deployment took a couple of hours. The plan was to place it in a location where we could see all the traffic.

We did it ourselves.

We have definitely seen a return on our investment. This is a pretty good product. If the opportunity continues, we'll continue to extend the license and keep it.

We did use other products, but they were small network monitoring tools. This is a better way because it comes in an all-in-one package. 

Scrutinizer is a good solution compared to other products because, if you use it correctly, it gives you a lot of data and it has good integration. With other products, we may have to install additional modules or do some additional deployment and integrations, which takes time and maintenance. Scrutinizer is all in one box so we don't have to worry. It internally integrates all the features we need.

Go with it but make sure that you have enough storage. If you don't have enough storage then you'll have to expand it. Talk to the Plixer guys to get the right configuration, depending on your environment.

We see things that we did not see before. It's opened up peoples' eyes, among our network folks. Overall, it has had a good, positive impact.

It's a product where we don't have to give too many people access. There are two or three people, admins, who are watching it, including me. They are network administrators and our system administrators. For deployment and maintenance it requires just one person.

We are using it as one of the key elements in our monitoring infrastructure, certainly on a daily basis. It's very good. It's almost there. With each version they have been improving features. If you compare the latest version which we are using, it's much better than the old versions they had. There are pretty good feature improvements and it's good enough for us for now.

The primary use case is to analyze the flow found within the network. It helps us understand how the network is used, e.g., if it is mainly used for email or private application.

It is very difficult to use functionality and provide features to understand how in the future the network will be used because the application is growing and developing so fast. So, the data flow could be exponential. That's why it's a daily challenge to understand how the network is in use and how we can manage to renegotiate the contract to improve the bandwidth, but it has very good tools concerning the network and network analysis. It has helped us a lot with troubleshooting.

I am using the latest version.

If an application is encountering an issue, and some people say, "Oh, this is the network's fault." We need to prove otherwise the problem application isn't working. Therefore, Scrutinizer helps us to verify the info and comply.

We have SQL Server all around the world. Because most replication happens almost equally, if we want to understand how the replication is doing, we can use Scrutinizer to put a filter on it. We can match older servers around the world, comparing the data transfer from each site to understand if some behaviors are different and why they are not the same. The tool helps developers to improve the application.

We use the solution specifically to help reduce the time to resolution for network and/or security events. It reduces the time to resolution by two to three hours (if everything is done by hand). With Scrutinizer, it takes maybe 15 minutes.

People are usually calling me, or bombing me by emails, and asking me to check what exactly is happening. So, Scrutinizer helps me have a better picture of network traffic and a few security issues.

It has a very user-friendly interface. 

The mapping is most key. It is very important for us and is very nice. It's important for us to see who is communicating with what and where. So, we have had many requests to understand in the network which devices are connected to others. Most people don't have this information or are able to establish a map of data flow everywhere around the network. Scrutinizer can really help with this. We are using it to understand who is talking to what, how, and which protocols can help us to improve security and analyze flow.

We use the flow analysis and graphical interface to analyze a different flow along with using some filters in order to drill down where the problem is coming from. These are the main features that I use Scrutinizer for. We implement them in specific reports. But, with so much information, in the end, we had to stop.

We have tried to extract a map of data flow information, but I think we have to use a JSON query with API in order to query Scrutinizer to pull out some information in order to make some correlation with other third-party tools. We never had the opportunity to do this. It is something that would be nice to do, but it's very labor intensive.

I really would like to exploit the metadata to match it with other applications using the API, but this is not yet available. I'm not sure that we'll go that way because all the work that we have to do in order just to extract the metadata from Scrutinizer. We'll have to correlate with all the information from other systems. For that reason, I'm not sure it's going to happen. It will be very interesting though. 

I would like them to improve the update process. It's so complicated now that it switched to Linux. This makes the server more stable because before we were running it on Windows. The fact that they use Linux is very good and makes it more stable. However, updates never happen in one day or on our own. So, every time we need to call Plixer to proceed with the update, and they are very efficient in that. However, if they could make it a bit easier to upgrade, e.g., a click from the web interface to update the system, this would be nice.

For updating the Scrutinizer platform, when we have the actual data, it never happens in one day. Every time we have the data, we are obliged to install a new server in order to integrate the old data, and every time it has a problem. Most of the time, we were obliged to scrap all the data because we couldn't transfer it to the new server. So, it would be very good if they could improve this part.

Concerning the NetFlow, we have encountered many issues with some routers that don't send proper tickets. All the time, we're obliged to logon to SSH and run pcap. Pcap is just the packet capture. We are obliged to enter into the Linux to run some pcap on the common line, which is not great. It would be very nice if they integrated the pcap features through the web in order to analyze them. It's very easy. Most of the tools that we're using, and that are on the market, provide this feature. It would be great if Plixer integrated the pcap functionality through the web interface without having to enter into the Linux system.

The security part could also be improved. It would be great if they could implement a better algorithm inside the Scrutinizer to detect if there were attacks. The current algorithm to check if there has been a DNS attack is very light.

I have using the solution for a pretty long time, since 2013.

It is quite stable. We did just encounter a very strange device (a network scanner) which sends us so many flows that the device almost crashed the server of Plixer. However, this is exceptional. We just discovered this issue about a one week ago. Otherwise, Plixer is very steady and has worked very well. We usually never encounter an issue. It is great. 

Because we use the main dashboard for maps to understand the use of the link and present it on the big screen TV, sometimes we are obliged to reset the browser everyday in order to refresh it. We had some little bugs because of this, but we don't know yet if this is coming from Mozilla Firefox, the browser, etc. Otherwise, it is very good.

It is very good. It's very scalable, as long as you have their license.

There are no more than 10 people who have access to the solution. We have 10 to 15 administrators with accounts who are technical. 

Two network administrators are more than enough for deployment and maintenance. Usually, one network administrator is taking care of this. Sometimes, I'm backing up, but otherwise, only one person is necessary to manage it.

This was our first solution to collect the flow. We were looking for a device for a long time, and we are very happy with Scrutinizer.

The first time the initial setup happened with an integrator, and it was very easy because we just implemented on Windows. After that, we changed to the new version of Scrutinizer, then we just call Plixer in order to do it because there are too many things to take into consideration, especially if we don't want to lose data. This also has room for improvement.

Anytime a deployment happens, because it's Linux, we require the help of Plixer. We are very happy to work with Plixer. They are very efficient and know what they are doing. With one simple call, they can help us update the system.

The initial deployment was done by Plixer, so it took one hour to install it. We provided the OVA to deploy it, then Plixer configured it. The new implementation was one hour and very fast. 

I would base ROI on the time that we gained and productivity. It is difficult to make a return of investment based on productivity. Mainly, I would say the time saved.

The license is per device. We have 50 devices.

We just renewed. The pricing is 5,000 euro per year. This is the final price. All tax (20 percent) is included.

We did look at other vendors and solutions, but because of our current monitoring system, we needed a complimentary system. During 2013, we made this substantial investment using Plixer. But, if we had to change everything now, it depends on the correct strategy. To replace Scrutinizer would be very difficult. That's the reason way we don't want to change it.

In terms of monitoring, the biggest competitor would be SolarWinds because they integrate an operations manager from another managing giant. They also provide a data flow collector and reporting variability with extensive monitoring ability for SMTP and troubleshooting. So, if you want an all in one solution, then maybe it will be different with them. 

Most users in our company have all the monitoring tools, people prefer to logon to Scrutinizer to see how the network is going instead of using all the monitoring tools because it is so user-friendly.

It is a pretty good tool.

The deployment plan was to help us be more efficient and proactive regarding data flows and security on this domain.

It helped me realize the main data flow is not controlled by anybody. By using these tools, it made me realize that developers and all these people that create applications don't know anything about the application that they've developed. It made me realize that developers are developing approximately. They are not very precise when we analyze it.

You can trust the Plixer developer, because they are a very capable company. If you really want to know what's happening on your network, this is one of the best tools that you can use. Especially after something happens, you can really use it and count on the tool to help find out the issue.

I would rate the solution an eight (out of 10).

I use Plixer Scrutinizer for Network traffic analysis.

When comparing Plixer Scrutinizer to NetFlow Analyzers and Microfocus NPS (Network Performance Solution), the features I found most valuable in Plixer Scrutinizer are the ease of access, particularly in the GUI, and the ease of the solution.

The most valuable features of Plixer Scrutinizer are its ease of use, accessibility, and UI.

I would recommend having more data points. Plixer Scrutinizer cannot handle high traffic volumes.

This is NetFlow Analyzer, and the number of data points, or the massive volume of information is stored. There are numerous processes running inside a router. As a result, a massive amount of data is being logged in this Plixer Scrutinizer. 

It is my understanding that when the flows are too high, the solution cannot handle them, and it is not simply a matter of scaling it up. For example, on ACI, you can define Cisco ACI core switches, and it is found that on Plixer Scrutinizer they are unable to handle the traffic volume. 

When I'm talking about a core switch or another switch that has a large amount of traffic flowing through it, the solution is also incapable of handling it.

In terms of data aggregation and storage, while I was not managing it, one of the feedbacks, specifically to this solution. I can't comment further on the technical side of things, but from a user standpoint, the team was only keeping the real-time log for one day. Then, for three days, it switches to five-minute aggregation. It switches to one-hour aggregation for one week. For one month, it will be aggregated on a daily basis, to save space. 

It aggregates the data points and removes the individual real-time data points before reducing the data points to conserve storage. I would suggest an improvement in data storage, or how the data is archived and sold so that enterprises have more room to keep data for a longer period of time with less aggregation. It will be kept for real-time value for a month, rather than just one day.

I've been using Plixer Scrutinizer for nine years, but I haven't used it in the last year.

I don't remember what version we were using because I haven't actively used it in the last year, but it was one of the more recent ones.

In terms of stability, it was good, but I wouldn't say that it was excellent.

I have seen a few crashes, however, it's very rare. While it is stable, there is always room for improvement. But it's fairly stable, and in the user experience, it remains consistent.

The solution's scalability is struggling on devices with a large number of flows.

ACI from Cisco, and not the Data points. Data points are improvements to how data is stored or archived. I've noticed that the solution is inconsistent on devices with a large number of flows, such as core switches for Data centers, or Cisco ACI.

To rephrase, the solution is suitable for a brand router or an internet switch, but it is not suitable for, at least in our environment, a core switch within a data center where the number of flows and communications will be high. From what I understand it is that the solution is not very scalable in a high volume traffic environment with a large number of flows.

This solution is used directly by 50 people in our organization. Most of the users were network engineers.

The solution received positive feedback. The usage was already on a daily basis. No further increases were anticipated or planned, but it was used extensively throughout the organization.

I am not aware of the pricing.

I am not an expert user or an administrator of the solution, and I have not recently used it. 

I am a problem manager. I conduct deep-dive analysis and retrospective analysis following the incident. To determine the root causes, we must examine all of our solutions in the application landscape.

I would strongly recommend this solution to anyone who is interested in using it.

I would rate Plixer Scrutinizer an eight out of ten.

Our primary use is troubleshooting. Our secondary use is capacity planning, investigations, and reporting. We use it with multiple vendors sending flows to us.

The solution helps us enrich our network traffic. It's really because of the ability to do host-to-host troubleshooting. We can see and isolate where the challenge or problem might be.

When used to troubleshoot a potential bad actor or issue, we have literally able to cut down our time to resolution drastically. For example, we had a "runaway instance" of hogging and taking up excessive resources from a source to a destination, and this allowed us to isolate it within minutes. Any tool of this type, if you know how to use it, will drastically reduce your time to troubleshoot.

The whole thing is valuable because it's such a massive product. We love every bit of it. We use every bit of it that we can. The reporting and generating troubleshooting reports would be the best feature; our host-to-host conversation reporting.

Knowing that they're coming out with a new user interface, that is an area where there is room for improvement. There are so many variables. They should limit the variables in the user interface and create some classes, like "simple," "novice," and "expert" to narrow down the variables within it.

We have been using the solution for about five years. We keep the version up to date, within 30 days of whenever it's deployed. We use it on-premise, but we literally just asked for a quote for the private cloud version.

It's rock-solid. 

It sits there and it runs solidly. There are multiple people in there every day doing some sort of report-generation or review. We don't have any plan to expand usage.

The scalability is excellent. It more than meets our needs. We had a certain size and we've had no problems scaling up and down.

The solution's technical support is second to none.

They set it up for us. It was straightforward. Start to finish, we were done in two days because that's how long they were onsite.

It was done by the vendor. Our experience with them was fantastic. They are some of the most knowledgeable people. I would put their knowledge — the people that they have and how long I've worked with them, how long they retain them, and how good they are, and how much they all know — I would put them on par with the best I've worked with in my 25 years in IT.

Our entire solution, amortized over five years, is in the vicinity of $40,000 to $50,000 a year. There are no additional costs because they're appliances. We buy them full-blown.

We liked this one the best of the ones we evaluated. We chose Scrutinizer over two other solutions. One was the incumbent but it was so long ago that I don't remember its name. We also reviewed LiveAction LiveNX.

The capacity the Plixer system can handle and the cost of that capacity were among the deciding factors, as was the performance when you run reports and get results. This is a big tool and it's analytics. Minutes count when something's broken. Scrutinizer did it faster. If something took five minutes, Scrutinizer took three.

I don't think it lost in any category that we cared about.

Compared to the other solutions, it is in the top two for usability, and it is at the top for capacity, performance, and cost.

In addition, the vendor's years of experience in delivering security and network visibility influenced our decision absolutely. We knew their support was excellent, that the vendor has the knowledge, and there was also the fact that they did this one thing and this one thing only. They concentrate on doing it really well. It wasn't a secondary offering. This is their job. This is their only task, and they do it really well.

Whatever other solutions you want to look at, benchmark them against this solution. No matter what product you're looking at, do a bake-off with this and see who wins. If you don't give him a chance, you're not going to know. You're going to miss out. I really feel, after reviewing three at one time and knowing some other ones, the bang and performance for the dollars, and the capacity and the flexibility; it's really second to none in those situations. Other ones might have matched it in one or two of those criteria, but all they did was match it. They didn't win in any of them.

It's a collector of information and it works great.

Our biggest lesson from using Scrutinizer is that, even as you generate reports and use it, it feels like an educational tool. It helps to educate us. You learn a lot more about general networking using the tool mainly because you understand it, in the same way you learn your ABCs before you learn to spell. It's the whole crawl, walk, run theory.

There are about 25 people using it, and their roles are all IT infrastructure. This helps everybody in the organization, all 3,500 people. But if you ask them, aside from the 25, only five in the broader organization would know that it helps them. You couldn't even ask them whether it helps them because we get warnings and reports and we're able to isolate and troubleshoot in ten minutes an issue that might have taken more than ten minutes. That's why we have the tool. We let everybody view certain things, so if I click "Send a Report" to somebody in IT, all 500 people in IT could look at it and it might mean something to them; it might not.

In terms of maintenance, there are only two people who maintain and run this on an ongoing basis and it takes less than one percent of their time. They have plenty of other stuff to do. That's why it's good to have this tool. It's just stable and solid.

It's a NetFlow collector.

It helps provide reporting information to our customers, which is also part of certain regulations that we have in the UK. 

The solution is similar to an automation process because we can automate and schedule reports. From a workflow process, the pipeline is automated. We would need to have a lot of people doing many reports in Excel instead of using one product. The solution emails us when we need it and on a periodic basis automatically.

The insight the solution provides as a result of its correlation of traffic flows and metadata is very good, fast, and accurate. It is one of our go-to tools when there is an issue and we want to do some accounting on the network.

The solution has helped reduce the time to resolution for network and security events by three to four hours.

Visualization of the network traffic is the most valuable feature. It allows you to drill into information quite quickly.

The solution helps enrich the data context of our network traffic. It allows us to easily visualize data flows and data usage. This helps keep management happy.

It would be useful if there was a way to back up the configuration information. E.g., if you wanted to deploy a new instance or disaster recovery, you could quite easily deploy and restore the config, as opposed to having to restore all the NetFlow data. If there was just a button that said "backup config information", that would be good.

About four years.

We're happy with it. The solution is stable.

We have one person who is required for deployment and maintenance. Their role is network administrator.

It's scalable for what we need. It has a lot more functionality than what we use. We can distribute the collection engine and some things like that, but we're not using that because we don't need to. It is there if we do need it.

There are varied roles across different teams. There are about 20 users, in total, who are mainly network operators.

The technical support has been excellent. Any problems that we have had, the technical support has been able to remedy and resolve them. But, there haven't been very many problems.

The workflow integration within a single platform has allowed us to remove redundant tooling. So, it streamlines that process into less workflows. It's allowed us to consolidate network statistical information. We have eliminated tools like SolarWinds, ntop, and some Linux utilities.

The primary reason that we switched to Scrutinizer was the interface. I saw a demonstration of the product at one of the security seminars where it was advertised as Splunk for network data. That's exactly the type of product we were looking for and it gave us that functionality. It was also able to deliver as expected.

Other requirements that we had were that it was multi-vendor, scalable, and a single-appliance solution. So, we didn't need to have a lot of database servers or Microsoft Servers and could run it as a virtual machine.

The product, Scrutinizer, was simple and straightforward to set up. Where we had trouble was not with the actual Plixer product, but with the sFlow sending. Although the issue wasn't with Scrutinizer, the support was able to help us resolve the issue.

The deployment took two weeks, start to finish. We had a test environment. A large part of those two weeks was setting a test environment up, having to play around with how we send data to Scrutinizer, and the NetFlow data. When we did a pilot, it resolved any problems with Scrutinizer directly. Then, we deployed into the live environment.

We deployed it. Plixer was there with technical support from the sFlow perspective. We didn't need them for the actual deployment.

It probably saves somebody at least one day a month at minimum.

We have increased the license over time. We have added more licenses as the network has grown.

There is a recurring maintenance fee after the initial purchase or if we want the license upgrade.

We already had some solutions in place. So, we evaluated Scrutinizer, which did what we needed it to do. At the same time, we were evaluating open source and SolarWinds.

Scrutinizer does exactly what we need it to do. We're very happy with it. We're not looking to change in the short-term or long-term. It's a product that runs without any issues and gives the information that we need.

Compared to previous solutions that we have used, this solution is a lot more intuitive, less clunky, and resource-hungry.

• Remember to save the reports.
  
• Give reports different file names.
• Understand how to back up and restore the configuration information. 
• If you use the building tools for the sizing for history information, they're quite accurate. 
• If you want to go back many months or years, you need more storage for that. 
• If you want a higher resolution to get into the data, make sure you size appropriately.

Try the free demo or evaluation copy of it. You should be happy with it, if it does what you need it to do. 

I would rate the solution a nine (out of 10). 

The primary use case was statistics. Now, it's mainly security and operations.

I am using the latest version.

It has become an essential and helpful tool for in my daily work. If we didn't have access to the tool, we would have more difficulty getting a long-term overview on the growth of our network. As we have gathered statistics for more than 10 years, we know about the implementation of traffic on our network to also justify our work and investments. From my point of view, it would be more difficult without a NetFlow accounting tool.

The solution helps enrich the data context of our network traffic. A very good example is a feature recently discovered denied firewall flows, which helps us understand what's going on in our DMZ. It also helps us figure out misconfigurations, It is really a very helpful feature.

It shows us the saturation of the network of devices. It gives us a clear view of the flows in the network to understand, for instance, planning upgrades in the network to get an idea of what's going on in the network for traffic flows. It gives us insight, for instance, on what's going on our VPN Client. There are a lot of things where it provides very helpful information. It also gives us our security reports with quite detailed information on what's going on in the network, and whether there are data exfiltrations and so on.

In a few cases, it has helped resolve network events. It has also helped resolve security events. We found a couple of security issues that we wouldn't have found without the tool.

• The automatic reports that we use for statistical purposes.
• The security analytics.
• The security alarms.

I have been using it for more than 10 years. My company has been using it longer.

On a scale from zero to 10, the stability is about an eight. From time to time, we have some issues that need to be fixed by their support. Usually, the support fixes the issues quite quickly. I would say it is between good and very good, in that range.

There is one person (the head of the network group) who maintains the server right now. There is also a backup if they are not available. We have a few people who are able to do some configurations on the system.

My personal impression right now is that we've reached a limit, or we are near a limit of flows per second, because we see that our system is getting quite slow. I suppose it's a hardware issue, not an issue of the software.

The actual size of the network is above 3000 users.

They are really great. With my most recent experience, two days ago, they responded quite quickly. They're immediately available. Usually, they have a solution to fix the issue during the call or web conference. With the most recent call, I had four questions and issues. They didn't say open four cases. They fixed or answered the four questions, then asked me whether I had other questions at the end. The support is perfect.

I never used another NetFlow accounting solution. I got to know the NetFlow concept at my current company.

The initial setup didn't seem to be that complicated. I found it already implemented, but we did a lot of migration steps. It seems to be quite easy to implement.

If I would have to implement it again, Scrutinizer is not that difficult to implement versus any other appliance. It is more complex to configure the exporters, but there is a lot of current, good documentation on the Plixer site for this.

In our situation with 25 exporters, it might take a half a week to do the implementation of the server. It's usually performed by Plixer, or with the help of Plixer and the hotline. First of all, I would use the test license to do a proof of concept to do the implementation. Then, I would test one or two devices, gathering some reports. I would also create an implementation plan.

We have seen ROI.

We recently bought a license upgrade, so we will integrate more exporters. We upgraded from a 25 exporter license to a 50 exporter license. Therefore, there will be more flows, and this will be an extension.

Compared to other solutions, the functionality Scrutinizer delivers is better.

I have one comparison to another product, which also has very basic NetFlow accounting.

When dimensioning the server hardware, we decided to have many CPUs, much memory and a large storage, but we learned that the storage has to be as fast as possible. It would have been better to invest in SSDs instead of HDDs.

We thought about using FlowPro. We see a very good use case for it, but right now we are working just with the flow collector for enhanced reporting.

It is really a very good security improvement. In the last two years, we learned that it's a very good security tool to learn more about what's going on in the network, not only in terms of network saturation, but mainly in terms of security incidents and break out.

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

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.

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.

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.

I have used the solution for about five years.

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

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.

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

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.

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.

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.

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.

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.