I installed Scrutinizer 100 times and here’s what I learned

As a Presales Engineer, I spend a good portion of my time helping with Scrutinizer installs and helping troubleshoot unique use cases for end users. In my 7 years of doing this, I’ve noticed a lot of commonality between installs even in disparate environments. I hope to add more to this list as time goes on and trends in the industry evolve further.

How to deal with the consumption gap

I started seeing a trend in the industry after the first few major data breaches happened: buy more tools! Enterprises started purchasing large numbers of SIEMs, packet capture solutions, IDS/IPS, and CMDB tools to help figure out what was happening on their network and make sure they stay out of the headlines. But while I do believe that you need some useful tools in the toolbox, you will also need a skilled engineer behind them. With the acquisition of new tools but not enough time to learn them, are you really in a better place than before?

Have no fear. Through APIs, integrating tools has never been simpler. I often find that integrations with PCAP, SIEMs, and even IPAMs can supplement our solution as well as the tool we are integrating with.

A final quote I will leave you with on this topic is “Learn workflows, not tools.” Learn how to find/troubleshoot and fix problems rather than an entire product suite. This will give you immediate benefit and use of the system without the headache of juggling different tools and feature sets.

Networking fog of war

I can’t even begin to count how many times I’ve heard the phrase “that shouldn’t be happening on our network” or “we need to have someone look into that” when looking at outbound traffic to a nefarious country/domain from data center servers. If you are reading this and saying “how does something like that even happen,” I ask you: before flow data, how would you find out that traffic was happening? Send logs to your SIEM? How about if that traffic was a few bits/s over the course of 6-12 months?

SIEMs should be used for event management and not traffic recording. Again, this is why we see time and time again that companies have all the tools, but still get breached. Finding out where the strengths and weaknesses are in particular toolsets will allow you to know where you have gaps and how to best fill them. SIEMS are incredibly useful for giving you correlated data around an event but often when trying to investigate networking issues, you end up having to sift through too much extra information to make it viable.

Charting the unknown is fun, but try not to bite off more than you can chew. A simple workflow that you can start with is figuring out what are the top 25 applications used on your network (bonus points if you have Layer-7 visibility from Palo Alto, Cisco NBAR, Packet Brokers, etc.). You will probably find protocols you didn’t know about or business units using unknown or unapproved applications.

Network forensics

With this newfound insight into the network, we will sometimes find data exfiltration via bad actors, infected PCs, or even vulnerable servers. Part of the initial benefits of network visibility is the new set of eyes that you gain into any potential threats or security events.

We find that even network operations teams like seeing this data since it can (and often does) affect critical applications or services. We can couple this data with machine learning algorithms to provide real-time alarms (that can be integrated with your SIEM) to help provide not only visibility, but also context around the event.

I hope you found this informative and interesting and if you would like to see how Scrutinizer can help fix your network, feel free to reach out to us!