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:
- 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. - 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. - 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. - Eradication: Be prepared to use a variety
of eradication techniques to remove malware from infected systems. - 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. - 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.
