Critical Control 12 : Malware Defense

Published: 2011-10-18
Last Updated: 2011-10-18 14:31:13 UTC
by Stephen Hall (Version: 1)
3 comment(s)

This diary has been posted on behalf of Russ McRee.

Those of you who are regularly committed to the task of protecting your enterprise from malware are
well aware of the pain points. Critical Control 12: Malware Defenses offers nine prospects for success in
the battle against a continuous and pervasive challenge.

Amongst the quick wins are easier methods such as preventing auto-run content; in the context of share
jumping worms such as Harakit/Renocide this will definitely help, but there are additional tactics that
supplement the list found in Critical Control 12.

1) In general, is there really a need to allow initiated outbound sessions from the likes of
production web servers? Preventing web browsing from production environments will definitely
cause whining but it can reduce the attack surface significantly

2) Commercial SIEMs clearly support #6 (automated monitoring tools should use behavior-based
anomaly detection) but correlation needn’t be limited to expensive solutions. The likes of
LogParser for Windows users or some strong grep, sed, and awk kung-fu for *nix users can be
utilized to create simple correlation tasks.

3) As part of #8 (continuous monitoring on outbound traffic) consider monitoring DNS and making
use of blocklists. While this entails much work (Advanced), particularly at scale, the ability
to blackhole hosts making requests for malicious domains has clear value. Guy Bruneau just
provided an update for this tactic a few days ago. Also, in support of correlation activity, if at all
possible, some semblance of a network baseline (known good egress) can be very useful even if
only utilized in high value networks.

4) To supplement #9 (an Incident Response process that allows for malware sample handling)
implement a very clearly defined process; deviation from established, tested standards risks
further outbreak. There are somewhat dated resources to draw from to help define initial
process, including NIST and CERT but there’s a critically important component related to the
overall malware incident response process for you to consider. DRILL! If you don’t practice
this activity (actual response as well as transport and analysis) on a regular basis you can’t
know what you don’t know. Operate under the premise that “no battle plan survives contact
with the enemy” every time you conduct a drill, improve via lessons learned, and implement
enhancements; you’ll be more likely to “survive contact.” Undertake this activity with other
teams upon which you have dependencies. Trying to quarantine an outbreak on specific VLANs
without the help of your network team, or deploying an emergency hotfix or patch without your
systems admins won’t make for a very good drill or tabletop exercise. Varying scenarios (worms
vs. Zeus vs. APT) will help test the boundaries of your skillsets as well.

What’s working for you in the fight against malware? Let us know via the comment form.

Keywords:
3 comment(s)

Comments

What’s working for you in the fight against malware?

Linux

(a bit tongue in cheek ... but)
What's working for the fight against malware....hmm, Management. Oh wait, Management is blocking our attempts at disabling things as basic as autorun. But when SHTF I have complete control, so I isolate, quarantine, patch, document (in hopes of...you know, preventing this from happening again).
What about least privileges for end points? Disabling local admin goes a long way toward preventing malware from taking hold in the first place. And I know it should never be the only solution in place but AV still can play an important role when other controls fail or are bypassed.

Diary Archives