Security Report Season: what malware does versus what it is.

Security Report Season: what malware does versus what it is.

Security Report Season: what malware does versus what it is.

Oliver Tavakoli, CTO, Vectra Networks
April 2, 2014

The first quarter of every year in the security business brings every imaginable retrospective of all the bad things that happened the prior year. This year is no different. As I read this year's crop of reports (this required several cups of coffee), I was struck by the fact that much of the focus continues to be on malware families, which I call "the race to win the naming game," and the number of zero-day threats found.

The naming game is always an interesting one. It leads to names like Kelihos (aka Hlux), ZeroAccess (aka Sirefef), Zeus (aka Zbot) and the usual rogues' gallery of malware. While the desire to name things is all too human (after all, it helps us communicate about complex things with very little effort), when you juxtapose the number of malware variants against the desire to name them all, you can see that we're facing an uphill battle.

So, what's the alternative? My personal preference is to focus on what the malware actually does, rather than what it is. At the endpoint, this would entail describing the vulnerabilities the malware exploits and the way in which it persists in the infected system. In the network, it would mean describing the manner in which the malware communicates and the ends which that communication seeks to achieve.

My company is in the business of divining truths about attacker behavior from network traffic, so our descriptions utilize the following taxonomy:

  • Command and control (e.g., pull, push, peer-to-peer)
  • Botnet monetization (e.g., ad clicks, spam, bitcoin mining, SEO)
  • Reconnaissance (e.g., slow and fast host discovery, mapping out DBs accessible via web servers)
  • Lateral attacks and spread (e.g., brute force, exploits against a number of internal hosts)
  • Exfiltration (e.g., use of internal relays, unusual outbound communication)

Describing what something does is a far more meaningful way to help customer incident response teams triage stuff that's already inside their network than impressing/scaring them with a new name of some piece of malware.

The zero-day stats are also interesting. What constitutes a zero day? After it has been used once, is it no longer a zero day? Is it a zero day as long as it is not widely known? Or until the vendor in question has released a patch? The practical point is that very few companies are truly the first to be attacked with a particular exploit. In fact, the largest cumulative damage occurs between the time the (now no longer) zero-day threat becomes relatively widely know and when the vulnerable systems are patched.

There are estimates for how long zero-day threats exist before they are found. The estimate is north of 300 days according to Andy Greenberg's description of a Symantec study. Further estimates for how long an attacker spends in a network before being discovered are north of 200 days, according to both Mandiant's summary from their 2013 annual threat report and Ted Schlein's editorial in WSJ's CIO Journal. But none of these estimates really measures when a zero-day exploit has become widely known vs. when it has effectively been patched in a vast majority of vulnerable systems.

The most effective way to tackle zero-day threats is by treating them the same as malware that's been around much longer: concentrate on the observable behavior and don't become overly reliant on reputation of payloads, IP addresses and domain names. Yes, I know no one calls it reputation anymore, but pick some words from a list that includes "threat, intelligence, cloud and crowd-sourced," and you will find that our industry continues to rely on what used to be called reputation.

So, as you read your favorite set of security reports during reports season, look beyond the drama of the whodunit and focus on what matters: what attackers are actually doing provides the most salient clue to their intentions.

About the author

Oliver Tavakoli

Oliver Tavakoli is chief technology officer at Vectra. Oliver is a technologist who has alternated between working for large and small companies throughout his 25-year career – he is clearly doing the latter right now. Prior to joining Vectra, Oliver spent more than seven years at Juniper as chief technical officer for the security business. Oliver joined Juniper as a result of its acquisition of Funk Software, where he was CTO and better known as developer #1 for Steel-Belted Radius. Prior to joining Funk Software, Oliver co-founded Trilogy Inc. and prior to that, he did stints at Novell, Fluent Machines and IBM. Oliver received an MS in mathematics and a BA in mathematics and computer science from the University of Tennessee.

Author profile and blog posts

Most recent blog posts from the same author


The Year in Review—and the Year to Come

November 30, 2020
Read blog post
Security operations

Office 365 Threats and Inversion of the Corporate Network

January 6, 2021
Read blog post
Security operations

Office 365の脅威と企業ネットワークの逆転

January 6, 2021
Read blog post