Where do I start?

We all end up asking ourselves this question as we dive into a new platform and a sea of new processes. Whether your job requires you to seek out issues within the network or hunt for anomalies and threats, having some guidance goes a long way. Plixer’s Scrutinizer platform uses flow and metadata analysis to provide rich context with automatic template recognition, which means little to no upfront configuration. However, I still believe it’s crucial to know where to start because data can be daunting, even when it’s your own. I’ve had a few opportunities to ride shotgun on threat hunting and network slowdown events and in my experience, these reports will allow anyone to bubble up the right issues using Scrutinizer.

Prologue for flow logs

The following assumes you have completed the initial setup and have at least one device configured to send flow data to Scrutinizer. If you are looking for the virtual setup guide, start here and if you need help setting up a flow record, start here.

In Scrutinizer, you begin by selecting an exporter—any device that exports flow (e.g. router, switch, firewall, probe, etc.). From there, run a default report against that device. You can do this by clicking on an interface from the dashboard or the status tab. The default report in Scrutinizer is called a “Conversation App” report and is part of the Pair Reports category, meaning the results will show a source and destination for the examined traffic. The Conversation App report groups the host traffic together to show traffic volume by application, which can be sorted by rate or total volume. This is the logical place to start (hence default report), so let’s call this the unofficial fifth report of this list.

After running any report, you will see a large blue rectangle at the top left of the screen. This is a drop-down menu that allows you to change the report type on the fly. You can change the current report on screen by clicking an option in that list or open a selection in a new tab/window by right-clicking the new report option. Both methods will preserve the data and time window already in focus.

Ana Molly

Pair reports show patterns in conversations, which provides insight for both network and security roles. Shown below is a “Client to Server” report, which shows inbound/outbound traffic for all client server conversations. For instance:

  • A network analyst might use this report to forecast volume for capacity planning or to identify a host conversation potentially causing the network to slow down.
  • A security analyst would use this report to ensure specific server resources aren’t talking to unauthorized hosts as part of an access control audit.

Both would be able to save a unique version of this report with a filtered down view to fit their use case. This means that a custom alarm, called a threshold alert, can be attached to each unique view of the report, allowing both teams to alarm on the activity they care about.

Scrutinizer network traffic analysis: attaching alarms to reports

Traffic volume isn’t always an indicator that something is amiss; turning to the flows can reveal some interesting details. This pair report, called “Connections by Flows,” is best viewed in a 1-minute data interval. To change your data interval, use the gear icon next to the blue report-type rectangle and change the data source from auto to 1m (note: if this takes more than a few seconds to load, use the gear icon to shorten the report range, too). A very high flow count indicates many small conversations vs. one larger conversation.

  • For network teams, high traffic volume isn’t always the cause of a slowdown. If a particular connection is flooding the network with requests, it can often introduce high amounts of latency, which slows down operational efficiency.
  • For security teams, this report can be valuable when hunting for those low/slow threats. By exposing resources that may be moving very small amounts of traffic, the flows can reveal a contrasting picture that exposes patterns of data exfiltration.
Scrutinizer Connections by Flows report

Those are great but… I need to know where people are going

Pair reports lend themselves well to dashboards and the report below is called “Hosts with Country” because geo-mapping is a crowd pleaser for both sides of the house. I was planning to mention the Autonomous Systems reports, but Jake Bergeron’s blog I installed Scrutinizer 100 times and here’s what I learned covers this effectively. If you happen to read this first, please stop here and go read his blog—I’m honored, but seriously that blog has what plants crave.

Scrutinizer Hosts with Country report

How much happens in a VMware VDS? Depending on the routing policy you may have a black hole when it comes to traffic between hosts.

  • For network teams, long-term trending for this environment is key to planning for SD-WAN or any cloud migration.
  • For security teams, any area with limited visibility can spell disaster. Collecting and storing these trends using flow data is much more efficient for audits and the budget.

I’m only going to highlight one report showing the connection path of a tenant connection, but it’s important to note that Scrutinizer offers five separate reports for VMware traffic. Plixer’s bloggers have covered the configuration for that environment at length across these 6 blogs:

VMware reports in Scrutinizer
Scrutinizer Pairs with Tenants report

Work separately, buy jointly

It’s a little mind-boggling that network and security teams will buy separate tools to accomplish the same thing just so that they don’t have to communicate. Siloed overspending is rampant, but there is light at the end of the tunnel. The cycle of tool and platform consolidation is catching on and Scrutinizer offers common ground and unparalleled value for those seeking an NTA platform.

What reports do you rely on? Would you use any of these reports to enhance your current workflow? Scrutinizer offers a free, yes 100% free, license—you don’t need permission or a team consensus to improve your workflow.

Whatever that process looks like, build it today with Plixer.

Stephen Tutterow

Stephen Tutterow

Stephen is a Field Engineer with Plixer based in Atlanta, GA. He especially enjoys breaking down complex subject matter into simple steps and working with customers on implementation strategy and design. When he’s not on the job, Stephen spends his time listening to podcasts, making puns, and enjoying the company of friends and family.

Related