How to stop hackers? Know your network

Until the perfect network monitoring tool comes along, knowledge of your network is your best defense

computer network 000016779847
Credit: iStockphoto

One of the best moves you can make to detect security threats is to monitor unusual network traffic connections.

Not every server needs to connect to every other server or even every workstation. Most workstations don’t connect to other workstations -- or to every server. In a perfect world, every server and workstation would be able to connect to the computers they're supposed to connect to, period. Anything else would be flagged as abnormal.

Those who launch APTs (advanced persistent threats) and other malicious hacks usually don’t know what these normal network flows are. They connect from the first compromised workstation or server to the next jumping-off point, regardless of normal or authorized traffic flows. Want to "detect the undetectable”? Then detect new, unauthorized traffic flows.

Unfortunately, this is a difficult task. Most companies lack a good understanding -- any understanding at all, for that matter -- of what should be connected to what. If you don’t understand what should be allowed, it’s hard to detect what’s abnormal. At the very least, you should create a diagram or spreadsheet documenting what should be allowed -- and include examples of connections that shouldn't happen.

The other problem is that perfect monitoring tool for network traffic flows -- to my knowledge -- doesn't exist. My perfect tool would:

  • Monitor and document existing network traffic flows between all endpoints
  • Put them in an understandable screen of information for review
  • Let network admins define which network traffic flows are or aren’t legitimate (this step would take a lot of research in most organizations)
  • Let admins define alerts for unauthorized or new information
  • Assign criticality to different network domains or connection types

Monitoring IP-address-to-IP-address traffic would be enough for me, but bonus points if the tool monitored port-level information (TCP port 80, UDP 53, and so on).

Early on I used simple network traffic monitor/packet analyzers like Wireshark to map network traffic. These network monitoring tools often have traffic flow maps that show what's connecting to what. But you’d have to run sensors on every endpoint and then bring the data together for analysis. It would be "analysis paralysis" for most organizations; plus, creating alerts would be problematic.

InfoWorld recently published an awesome overview of open source network tools: Nagios, Icinga, NeDi, and Observium. Each tool is part of the solution, but not enough. Some fail due to missing features. Some have tracking and monitoring, but lack alerting. Some have alerting, but they're not good at discovery. Others aren’t enterprise-ready.

Lately, I’ve seen customers employ an interesting commercial tool: Tufin’s SecureTrack. It's almost perfect. It's designed to track, manage, and optimize traffic rules (on firewalls, routers, load balancers, and so on). It reads the devices, collects the rules, analyzes, and suggests optimizations. It has an awesome graphical view of which networks (and other logically defined connection boundaries) can and can’t communicate with each other. On one screen you can easily see what boundaries can talk to what. It’s easy to see the intersections and pick out the networks and boundaries that really have no reason to talk to each other. It will even send prioritized alerts when a rule set breaks a connection pathway policy.

Only one feature is missing from Tufin SecureTrack: It doesn’t monitor individual endpoints. If I could merge it with a protocol analyzer or endpoint collector, it would be perfect.

What are your favorite network monitoring tools? Have you encountered anything that meets all my criteria? If so, let us all know about it in the comments.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.