Not a Fish Story: Tackle the Reel Network Security Issues

When last we gathered around the soft glow of the monitor, we shared the oft-told tale of troubleshooting random user complaints and the importance of scoring and storing instead of ignoring. This time, let’s turn the pages of a related story – a fish story so to speak…

In the rivers of data that flow in and out of our data centers, primary, and remote locations, the things we might catch are growing in number and diversity. Setting the metaphor aside for just a moment, some traffic leaves a user location headed directly for a cloud service, some is routed to and from the data center and the branch, some traffic is voluminous, some seemingly insignificant.

Back to our story. Often, it’s the big fish that get all the attention but sometimes it’s the little ones that should concern us the most. To illustrate, in the waters of the Amazon swims one of the largest freshwater fish in the world, Arapaima gigas, or simply, the arapaima. 

You can see why this big fellow would gather a lot of attention. However, in those same waters you can find something much smaller; twenty different species of this little guy:

Now, just because he’s smaller, doesn’t mean you wouldn’t want to know about him. In fact, you’d probably want to know he was there whether he was all by himself or part of a large shoal (TIL: A shoal is the proper name for a piranha party).

What has this brief fish story taught us? Putting all your focus and attention on the big things could put you in danger when the little ones start to slip through the net.

What’s the application, the point, the moral of the fish story? Don’t ignore the small things on your network.  

In this example, a real time threat map, based on flow data, warns that a user is communicating with a blacklisted host.

A couple things of note here:

1.     While suspicious/malicious hosts are constantly trying to find their way into your network, this event is of concern because the *destination* IP is the blacklisted device, meaning that one of our devices is actually responding back (things that are bad).

2.     The number of packets (1) and bytes (56). That’s a pretty small fish but clearly one worth paying attention to.

In a situation like this, the big fish, i.e., the stuff we would typically see on our TopN reports, really don’t matter. We need to quickly gather as much forensic detail as we can. That can only be accomplished if we’ve retained the relevant conversation(s) and associated host details. In analyzing our suspect device, this is the level of detail we’re looking for:

·       Who (User ID)

·       What (MAC address)

·       Where (VLAN, Traffic Group, Switch Port, Network Path)

·       When (How long as this been happening)

·       Why (A record of what led up to the suspicious behavior)

·       How…many users are manifesting this same behavior

As your rivers of bandwidth and lakes of data grow, don’t settle for only watching out for the big fish.