62
G
UIDE TO
M
ALWARE
I
NCIDENT
P
REVENTION AND
H
ANDLING
In a widespread incident, if malware cannot be identified by updated antivirus software, or updated
signatures are not yet fully deployed, organizations should be prepared to use other security tools to
contain the malware until the antivirus signatures can perform the containment effectively.
38
After an
organization receives updated signatures, it is prudent to test them at least minimally before deployment,
to ensure that the update itself should not cause a negative impact on the organization. Another reason to
use multiple security tools for automated detection and containment activities is load balancing.
Expecting antivirus software to handle the complete workload of a malware incident is unrealistic during
high-volume infections. By using a defense-in-depth strategy for detecting and blocking malware, an
organization can spread the workload across multiple components. A further benefit of having multiple
types of automated detection ready is that different detectors may be more effective in different situations.
Examples of automated detection methods other than antivirus software are as follows:
E-mail Filtering. E-mail servers and clients, as well as anti-spam software, can be configured to
block e-mails or e-mail attachments that have certain characteristics, such as a known bad subject,
sender, message text, or attachment name or type.
39
However, malware increasingly uses a wider
variety of characteristics; for example, a virus could use a hundred different subjects, any of
which could also be used for legitimate e-mails. Some viruses even generate random subjects or
attachment names, or create replies to existing benign e-mails, which might render e-mail
filtering methods useless. In addition, although most malicious file attachments have suspicious
file extensions (particularly .bat, .cmd, .exe, .pif, and .scr), the use of once-benign file extensions,
such as .zip, has become more prevalent for malicious file attachments.
Network-Based IPS Software. Most IPS products allow their prevention capabilities to be
enabled for specific signatures. If a network-based IPS device is inline, meaning that it is an
active part of the network, and it has a signature for the malware, it should be able to identify the
malware and stop it from reaching its targets. If the IPS device does not have its prevention
capabilities enabled, it may be prudent during a severe incident to reconfigure or redeploy one or
more IPS sensors and enable IPS so they can stop the activity. IPS technologies should be able to
stop both incoming and outgoing infection attempts. Of course, the value of IPSs in malware
containment depends on the availability and accuracy of a signature to identify the malware.
Several IPS products allow administrators to write custom signatures based on some of the known
characteristics of the malware, or to customize existing signatures. For example, an IPS may
allow administrators to specify known bad e-mail attachment names or subjects, or to specify
known bad destination port numbers. In many cases, IPS administrators can have their own
accurate signature in place hours before antivirus vendors have signatures available. In addition,
because the IPS signature affects only network-based IPS sensors, whereas antivirus signatures
generally affect all workstations and servers, it is generally less risky to rapidly deploy a new IPS
signature than new antivirus signatures.
Host-Based IPS Software. Some host-based IPS products can restrict certain executables from
being run. For example, administrators can enter the names of files that should not be executed.
If antivirus signatures are not yet available for a new threat, it might be possible to configure
host-based IPS software to block the execution of the files that are part of the new threat.
38 Incident handlers should also be familiar with the organization’s policy and procedures for submitting copies of unknown
malware to the organization’s antivirus vendors and other security software vendors for analysis. This practice can help
vendors respond more quickly to new threats. Organizations should also contact trusted parties, such as incident response
organizations and antivirus vendors, when needed and as permitted by the organization’s policy, for guidance on handling
new threats.
39 Generally, it is feasible only in highly managed environments to configure e-mail clients throughout the organization to
block certain e-mails or e-mail attachments.
4-12
58
G
UIDE TO
M
ALWARE
I
NCIDENT
P
REVENTION AND
H
ANDLING
4.3.3
4.3.4
Containment through Disabling Services
Some malware incidents necessitate more drastic and potentially disruptive measures for containment.
For example, an incident might generate so much network traffic or application activity, such as e-mails
or file transfers that many applications could effectively be made unavailable. Containing such an
incident quickly and effectively might be accomplished through a loss of services, such as shutting down
a service used by malware, blocking a certain service at the network perimeter, or disabling portions of a
service (e.g., large mailing lists). Also, a service might provide a channel for infection or for transferring
data from infected hosts. In either case, shutting down the affected services might be the best way to
contain the infection without losing all services. This action is typically performed at the application
level (e.g., disabling a service on servers) or at the network level (e.g., configuring firewalls to block IP
addresses or ports associated with a service). The goal is to disable as little functionality as possible
while containing the incident effectively. To support the disabling of network services, organizations
should maintain lists of the services they use and the TCP and UDP ports used by each service.
The service most commonly affected by malware is e-mail. E-mail servers can become completely
overwhelmed by viruses or worms trying to spread via e-mail. Shutting down e-mail servers to halt the
spread of e-mail–borne malware can largely contain some incidents very quickly. However, in some
cases, an organization might have unknown e-mail servers (e.g., a file server inadvertently running an e-
mail server) that also need to be shut down, which could slow containment. In less severe circumstances,
disabling portions of e-mail services might provide effective containment without causing the loss of all
e-mail services. For example, temporarily disabling unmoderated mailing lists might significantly reduce
the spread of malware and the strain on e-mail servers.
From a technology standpoint, disabling a service is generally a simple process; understanding the
consequences of doing so tends to be more challenging. Disabling a service that the organization relies
on has an obvious negative impact on the organization’s functions. Also, disabling a service might
inadvertently disrupt other services that depend on it. For example, disabling e-mail services could
impair directory services that replicate information through e-mail. Organizations should maintain a list
of dependencies between major services so that incident handlers are aware of them when making
containment decisions. Also, organizations might find it helpful to provide alternative services with
similar functionality. For example, in a highly managed environment, if a vulnerability in an e-mail client
were being exploited by a new virus, users could be blocked temporarily from using that e-mail client and
instead directed to use a Web-based e-mail client that did not have the vulnerability. This step would help
contain the incident while providing users with e-mail access. The same strategy could be used for cases
involving exploitation of vulnerabilities in Web browsers and other common client applications.
Organizations should also be prepared to respond to problems caused by other organizations disabling
their own services in response to a malware incident. For example, an organization that has a team
temporarily working for another organization might have configured the team members’ e-mail accounts
to forward their e-mail to accounts on the other organization’s e-mail system. In this case, if the other
organization disabled e-mail services, forwarded e-mails might be bounced back, then reforwarded, then
bounced again, resulting in a mail loop. If this happened, a handful of user accounts could cause a
significant degradation in e-mail services.
Containment through Disabling Connectivity
Containing incidents by placing temporary restrictions on network connectivity can be very effective. For
example, if infected systems attempt to establish connections with any one of several external systems to
download rootkits, handlers should consider blocking all access to the external systems’ IP addresses.
Similarly, if infected systems within the organization attempt to spread their malware, the organization
4-13
59
G
UIDE TO
M
ALWARE
I
NCIDENT
P
REVENTION AND
H
ANDLING
might block network traffic from the systems’ IP addresses to control the situation while the infected
hosts are physically located and disinfected. An alternative to blocking network access for particular IP
addresses is to disconnect the infected systems from the network, which could be accomplished by
reconfiguring network devices to deny network access or physically disconnecting network cables or
ejecting removable network interface cards from infected systems.
The most drastic containment step is purposely breaking needed network connectivity for uninfected
systems. This could eliminate network access for groups of systems, such as remote dial-in and VPN
users. In worst-case scenarios, isolating subnets from the primary network or even disconnecting the
entire organization from the Internet might be necessary to stop the spread of malware, halt damage to
systems, and provide an opportunity to mitigate vulnerabilities. Implementing a widespread loss of
connectivity to achieve containment is most likely to be acceptable to an organization in cases in which
malware activity is already causing severe network disruptions or infected systems are performing an
attack against other organizations. Because a major loss of connectivity almost always affects many
organizational functions, connectivity usually must be restored as soon as possible.
Organizations can design and implement their networks to make containment through loss of connectivity
easier to do and less disruptive. For example, some organizations place their servers and workstations on
separate subnets; during a malware incident targeting workstations, the infected workstation subnets can
be isolated from the main network, and the server subnets can continue to provide functionality to
external customers and internal workstation subnets that are not infected. Another network design
strategy related to malware containment is the use of separate virtual local area networks (VLAN) for
infected systems. With this design, a host’s security posture is checked when it wants to join the network.
This is often done by placing on each host an agent that monitors various characteristics of the host, such
as OS patches and antivirus updates. When the host attempts to connect to the network, a network device
such as a router requests information from the host’s agent. If the host does not respond to the request or
the response indicates that the host is insecure, the network device causes the host to be placed onto a
separate VLAN. The same technique can be used with hosts that are already on the organization’s regular
networks, allowing infected hosts to be moved automatically to a separate VLAN.
40
Having a separate VLAN for infected hosts also helps organizations to provide antivirus signature updates
and OS and application patches to the hosts while severely restricting what they can do. Without a
separate VLAN, the organization might need to remove infected hosts’ network access entirely, which
necessitates transferring and applying updates manually to each host to contain and eradicate the malware
and mitigate vulnerabilities. A variant of the separate VLAN strategy that can be effective in some
situations is to place all hosts on a particular network segment in a VLAN and then move hosts to the
production network as each is deemed to be clean and patched. One drawback of using a VLAN is that
the traffic from the infected hosts is still carried through the same devices as the production traffic; it
provides logical separation but not physical. As a result, large volumes of traffic on the VLAN, produced
by malware-generated activity and system updating and patching, could cause operational problems for
all users of the network devices.
4.3.5
Containment Recommendations
Containment can be performed through many methods in the four categories described above (users,
automated detection, loss of services, and loss of connectivity). Because no single malware containment
category or individual method is appropriate or effective in every situation, incident handlers should
select a combination of containment methods that is likely to be effective in containing the current
40 Microsoft has developed a platform for this called Network Access Protection (NAP). More information on NAP is
available at http://www.microsoft.com/windowsserver2003/technologies/networking/nap/default.mspx
.
4-14
56
G
UIDE TO
M
ALWARE
I
NCIDENT
P
REVENTION AND
H
ANDLING
incident while limiting damage to systems and reducing the impact that containment methods might have
on other systems. For example, shutting down all network access might be very effective at stopping the
spread of malware, but it would also allow infections on systems to continue damaging files and would
disrupt many important functions of the organization.
The most drastic containment methods can be tolerated by most organizations for only a brief period of
time. Accordingly, organizations should support sound containment decisions by having policies that
clearly state who has authority to make major containment decisions and under what circumstances
various actions (e.g., disconnecting the organization from the Internet) are appropriate.
4.3.6 Identification of Infected Hosts
Identifying hosts that are infected by malware is part of every malware incident, and particularly
important for widespread incidents. Once identified, infected hosts can undergo the appropriate
containment, eradication, and recovery actions. Unfortunately, identifying infected hosts is often
complicated by the dynamic nature of computing. For instance, people shut systems down, disconnect
them from networks, or move them from place to place, making it extremely difficult to identify which
hosts are currently infected. In addition, some hosts can boot to multiple OSs or use virtual operating
system software; an infection in one OS instantiation might not be detectable when a system is currently
using another OS.
Accurate identification of infected hosts can also be complicated by other factors. For example, systems
with unmitigated vulnerabilities might be disinfected and reinfected multiple times. Some instances of
malware actually remove some or all traces of other malware, which could cause the partially or fully
removed infections to go undetected. Identifying all hosts involved in large-scale incidents is often
particularly challenging because of the sheer number of infected systems. In addition, the data
concerning infected hosts might come from several sources—antivirus software, IDSs, user reports, and
other methods—and be very difficult to consolidate and keep current.
Ideally, all identification could be performed through automated means, but for various reasons
(described in Sections 4.3.6.1 and 4.3.6.2), this is usually not possible. Manual identification methods,
such as relying on users to identify and report infected systems, and having technical staff personally
check each system, are not feasible for comprehensive identification during incidents in most
organizations. Organizations should carefully consider host identification issues before a large-scale
malware incident occurs so that they are prepared to use multiple identification strategies as part of
implementing effective containment strategies. Organizations should also determine which types of
identifying information might be needed and what data sources might record the information. For
example, a host’s current IP address is typically needed for remote actions; of course, a host’s physical
location is needed for local actions. One piece of information can often be used to determine others, such
as mapping an IP address to a media access control (MAC) address, which could then be mapped to a
switch serving a particular group of offices. If an IP address can be mapped to a system owner or user—
for example, by recording the mapping during network login—the owner or user can be contacted to
provide the host’s location.
The difficulty in identifying the physical location of an infected host depends on several factors. In a
managed environment, identifying a host’s location is often relatively easy because of the standardized
manner in which things are done. For example, system names might contain the user’s ID or office
number, or the system’s serial number (which can be tied to a user ID). Also, asset inventory
management tools might contain current information on host characteristics. In other environments,
especially those in which users have full control over their systems and network management is not
centralized, it might be challenging to link a machine to a location. For example, an administrator might
4-15
55
G
UIDE TO
M
ALWARE
I
NCIDENT
P
REVENTION AND
H
ANDLING
know that the system at address 10.3.1.70 appears to be infected but not have any idea where that
machine resides or who uses it. Administrators might need to track down an infected system through
network devices. For example, a switch port mapper can poll switches for a particular IP address and
identify the switch port number and host name associated with that IP address. If the infected system is
several switches away, it can take hours to track down a single machine; if the infected system is not
directly switched, the administrator might still need to manually trace connectivity through various wiring
closets and network devices. An alternative is to pull the network cable or shut down the switch port for
an apparently infected system and wait for a user to report an outage. This approach can inadvertently
cause a loss of connectivity for small numbers of uninfected systems, but if performed carefully as a last-
resort identification and containment method, it can be quite effective.
Some organizations first make reasonable efforts to identify infected hosts and perform containment,
eradication, and recovery efforts on them, then implement measures to prevent hosts that have not been
verified as uninfected and properly secured from attaching to the network. These measures should be
discussed well in advance, and incident handlers should have prior written permission to lock out hosts
under certain circumstances. Generally, lockout measures are based on the characteristics of particular
hosts, such as MAC addresses or static IP addresses, but lockouts can also be performed based on user ID
if a system is associated with a single user. Another possibility is to use network login scripts to identify
and deny access to infected hosts, but this might be ineffective if an infected system starts spreading
malware after system boot but before user authentication. As described in Section 4.3.4, having a
separate VLAN for infected or unverified hosts can provide a good way to lock out systems, as long as
the mechanism to detect infections is reliable. Although lockout methods might be needed only under
extreme circumstances, organizations should think in advance about how individual hosts or users could
be locked out so that if needed, lockouts can be performed rapidly.
Sections 4.3.6.1 through 4.3.6.3 discuss the possible categories of infected host identification techniques:
forensic, active, and manual.
4.3.6.1 Forensic Identification
Forensic identification is the practice of identifying infected systems by looking for evidence of recent
infections. The evidence may be very recent (only a few minutes old) or not so recent (hours or days
old); the older the information is, the less accurate it is likely to be. The most obvious sources of
evidence are those that are designed to identify malware activity, such as antivirus software, spyware
detection and removal utilities, content filtering (e.g., anti-spam measures), and host-based intrusion
prevention software. The logs of security applications might contain detailed records of suspicious
activity, and might also indicate whether a security compromise occurred or was prevented. If the
security application is part of a managed enterprise deployment, logs might be available both on
individual hosts and in a centralized application log.
In situations in which the typical sources of evidence do not contain the necessary information,
organizations might need to turn to secondary sources, such as the following:
Network Device Logs. Firewalls, routers, and other filtering devices that record connection
activity, as well as network monitoring tools, might be helpful in identifying network connection
activity (e.g., specific port number combinations, unusual protocols) consistent with certain
malware.
Sinkhole Routers. A sinkhole router is a router within an organization that receives all traffic
that has an unknown route (e.g., destination IP addresses on an unused subnet). Malware
attempting to propagate may generate such traffic; thus, unusual changes in the traffic seen by the
4-16
Documents you may be interested
Documents you may be interested
