Critical Control 12 : Malware Defense - SANS Internet Storm Center

Critical Control 12 : Malware Defense
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.	Stephen 89 Posts Oct 18th 2011
Thread locked Subscribe	Oct 18th 2011 1 decade ago
What’s working for you in the fight against malware? Linux (a bit tongue in cheek ... but)	Anonymous
Quote	Oct 18th 2011 1 decade ago
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).	Anonymous
Quote	Oct 18th 2011 1 decade ago
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.	jtwaldo 17 Posts
Quote	Oct 18th 2011 1 decade ago

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.

Stephen

89 Posts

Oct 18th 2011

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

Linux

(a bit tongue in cheek ... but)

Anonymous

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).

Anonymous

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.

jtwaldo

17 Posts