Security

Follow this six-step malware response plan

Sometimes all the preventive care in the world won't protect your systems from the inevitable malware infection. What's the best way to handle it? According to Mike Mullins, an effective malware response plan includes these six steps.

As security administrators, we try to be as proactive as possible—applying patches and updates, conducting penetration testing, and establishing usage policies. Unfortunately, sometimes all the preventive care in the world won't protect your systems from the inevitable infection—be it virus, worm, or some other form of malware.

I've written before about the importance of creating an incident response policy, and I've told you specific steps to take in response to a security incident. But security incidents can vary widely in size and target. While it's imperative to have an overall policy in place, an actual incident response plan should depend on the actual event.

Case in point: The growing threat of malware infections. A malware incident response plan is not one that should focus on an active attack; instead, it needs to concentrate on the payload left behind on your systems.

What is malware?

Malware is malicious code or software secretly inserted into a system to compromise the confidentiality, integrity, or availability of the data or applications residing on the network. Malware incidents can cause extensive damage and disruption to a network, and they require costly efforts to restore system security and user confidence.

We can separate malware threats into five broad categories. Here's a quick overview:

  • Viruses: Self-replicating code inserts copies of the virus into host programs or data files. Viruses can attack both operating systems and applications.
  • Worms: A self-replicating, self-contained program executes without user intervention. Worms create copies of themselves, and they don't require a host program to infect a system.
  • Trojan horses: This self-contained, non-replicating program appears to be benign, but it actually has a hidden malicious purpose. Trojan horses often deliver other attacker tools to systems.
  • Malicious mobile code: This software with malicious intent transmits from a remote system to a local system. Attackers use it to transmit viruses, worms, and Trojan horses to a user's workstation. Malicious mobile code exploits vulnerabilities by taking advantage of default privileges and unpatched systems.
  • Tracking cookies: Accessed by many Web sites, these persistent cookies allow a third party to create a profile of a user's behavior. Attackers often use tracking cookies in conjunction with Web bugs.

These are the main categories of the malware threats threatening your users and your network. What happens when they succeed? An effective malware response plan includes these six steps:

  1. Preparation: Develop malware-specific incident handling policies and procedures. Conduct malware-oriented training and exercises to test your policies and procedures. Determine whether your procedures work before you actually have to use them.
  2. Detection and analysis: Deploy and monitor antivirus/anti-spyware software. Read malware advisories and alerts produced by antivirus/ anti-spyware vendors. Create toolkits on removable media that contain up-to-date tools for identifying malware, examining running processes, and performing other analysis actions.
  3. Containment: Be prepared to shut down a server/workstation or block services (e.g., e-mail, Web browsing, or Internet access) to contain a malware incident. Decide who has the authority to make this decision based on the malware activity. Early containment can stop the spread of malware and prevent further damage to systems both internal and external to your network.
  4. Eradication: Be prepared to use a variety of eradication techniques to remove malware from infected systems.
  5. Recovery: Restore the confidentiality, integrity, and availability of data on infected systems, and reverse containment measures. This includes reconnecting systems/networks and rebuilding compromised systems from scratch or known good backups. The incident response team should assess the risks of restoring network services, and this assessment should guide management decisions about restoration of services.
  6. Report: Gather the lessons learned after each malware incident to avert similar future incidents. Identify changes to security policy, software configurations, and the addition of malware detection and prevention controls.

Final thoughts

When it comes to responding to a malware incident, you can deploy all the detection and monitoring tools on the planet, but you still have to get your users involved! Educate your users on how to identify infections, and teach them the steps to take if their system becomes infected.

Miss a column?

Check out the Security Solutions Archive, and catch up on the most recent editions of Mike Mullins' column.

Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each Friday, and get hands-on advice for locking down your systems.

Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.

7 comments
AnsuGisalas
AnsuGisalas

There are twenty+ spaces missing from this article. If you hurry up and fix it, you won't get 20+ posts complaining about them ;) I think remedy step no. 3, containment, is very interesting. If we think just in terms of desktop PCs, we come to accept that pulling the plug is the first step... but what if there is a conflict between containing the infection and sustaining business operations? If the infected machine is something other than a workstation PC, if it is a crucial server, for example... when do you pull the plug? And can you prepare, so that you can restore business operations via an alternative? This is something to pay extreme attention to during planning... developing plans for makeshift redundancies, thinking out which machines could conceivably run which other functions, and what would be needed for that to happen. Then find out which files from the machine to be redundated (made that one up) you have to grab out of there before you pull the plug.

Doug Vitale
Doug Vitale

Disconnect infected hosts. Immediately update antimalware tools. Use change detection tools to discover unauthorized modifications to the file system, network device configuration, or application code. Review security event logs to identify suspicious activities, such as failed access attempts. Look at firewall/router logs or employ intrusion detection systems to identify signs of the malware's inbound and outbound network traffic. Look at DNS logs to identify internal systems that attempt to resolve known malicious domain names. Incidents in which you can reliably remove malware without rebuilding (i.e., wiping the drive and reinstalling the operating system) infected hosts are rare.

aaron
aaron

We have a simple solution here at Bit9...Don't let any new software execute, but automatically allow IT authorized software. This is a simple solution that can eliminate all Malware in your environment. "By the end of 2007, 75% of enterprises will be infected with undetected, financially motivated, targeted malware that evaded their traditional perimeter and host defenses" Gartner How do you prepare for that?

BALTHOR
BALTHOR

Go right after the heart of the matter and end virus forever.

mariama
mariama

mariama@capgemini.es

Lovs2look
Lovs2look

Well, blow me down...why didn't thousands of IT security people think of that? You must be a manager or something to think of that. WOW...moron.

smallbiz-techwiz
smallbiz-techwiz

I once worked in an organization where the IT dept. lost the political battle of being able to lock down user PCs and limit permissions. We had a group of rebel users that thought they knew as much as we did and didn't like waiting for IT approval whenever they wanted to install something new and untested. When upper management forced us to grant them local Admin permissions so they could install whatever they wanted, we switched to a different strategy. All security efforts were focused on protecting the servers and the rest of the network. Workstation problems were considered "hands off". We could offer advice, or re-image the PC. Otherwise, the users were on their own. Traffic was monitored so that if any workstation began broadcasting suspicious traffic, we could consider it a threat to the LAN and unplug them from the switch until the user removed the offending software. Meanwhile, that user would just have to use someone else's PC. Performance problems on many PC's resulted in user complaints and cries for "new computers". Once upper management realized how much this new "freedom" was costing the company, we got our authority back.