Welcome!

Network Aware, Business Secure

Michael Patterson

Subscribe to Michael Patterson: eMailAlertsEmail Alerts
Get Michael Patterson via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: CEOs in Technology, Cisco Virtualization Journal, Government News, Telecom Innovation

Blog Feed Post

How to Detect Advanced Persistent Threats – 2 Primary Technologies

Possibly the most difficult network malware to detect today is the Advanced Persistent Threat or APT. I’ve also heard them referred to as advanced targeted attacks. Before I digress on how to detect this insidious enigma, I would like to provide some history and clear up some misconceptions about this type of attack.

The APT defined: it was first used in 2006, when it was coined by the Air Force “to describe specific types of adversaries, exploits, and targets used for explicit strategic intelligence gathering goals,”.   It is not meant to purely describe Chinese threat actors rather, an APT can be initiated from anywhere in the world. Despite claims by vendors, China is not the only malware hosting country as shown in the following figure.

detect malware with NetFlow

Without getting into a long history on Advanced Persistent Threats, I’ll provide a short overview.  Breaking down the acronym we find:

  • Advanced -the adversary is conversant with computer intrusion tools and techniques and is capable of developing custom exploits.
  • Persistent -the adversary intends to accomplish a mission. They receive directives and work towards specific goals.
  • Threat -the adversary is organized, funded and motivated.

An APT is often not the typical brute force scan of the network.  It is a low and slow form of computer espionage generally used to target a specific government or business agency. How can we detect and ultimately stop it? First, here’s what often doesn’t work:

  • Host Behavior Baselines that look for scans on the network or invalid TCP flag patterns won’t catch an Advanced Persistent Threat. Comparing how a host usually talks on the network to how it is using the network now can certainly find threats but, this effort is unlikely going to help find an APT.
  • Packet Signature systems that watch for bit patterns usually aren’t effective at detecting an APT.  APTs often use secure connections on port 443 and encrypt their sneaky efforts.

What can be effective in the fight against APTs?

  • IP Host Reputation can often help detect APTs because it compares all connections with hosts on the internet to a reputation database. Connections to hosts with poor reputations, can raise warning flags.  These databases are updated frequently and the Command and Control (C&C) server participating in the APT could be on the list.
  • Setup a Honeypot and watch all communications to and from the internet. Then, watch who and with what the honeypot tries to communicate with on the corporate network.  NetFlow monitoring  is an ideal solution for this. NetFlow reports can tell us who the honeypot server is trying to communicate with, how often and with what port (e.g. TCP port 443). If any internal hosts are communicating in a similar way with the same internet host the honeypot is, you could have a problem that is worth investigating.

“We’ve learned that NetFlow can tell us who is talking to who across our network, but how can we tell if either who is a bad actor? By checking the reputation of the IP addresses at both ends of the conversation.“ – Mike Schiffman at Cisco

Layered Security is the Best Defense Against APTs
Beware of vendors that claim to provide the only complete solution to stop advanced targeted attacks, there is absolutely no proven single technique to catching APTs.  A layered security approach is the best defense against APTs.

 

Michael Patterson
Founder and CEO
Click to download Scrutinizer now!
Join NetFlow Developments on Linkedin.com

Read the original blog entry...

More Stories By Michael Patterson

Michael Patterson, is the founder & CEO of Plixer and the product manager for Scrutinizer NetFlow and sFlow Analyzer. Prior to starting Somix and Plixer, Mike worked in a technical support role at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix and Plixer.