Data Security | Feature

4 Steps To Combat Malware Enterprisewide

In the fight against malicious software, it’s not enough to treat individual infected machines. Here’s how to develop a malware strategy that protects an entire campus.

Too often, organizations make the mistake of treating malware infections as a series of independent occurrences. Each time a malicious program is discovered, IT simply cleans up or rebuilds the affected host and then moves on with routine operational tasks. Yet this approach doesn't allow the institution to keep up with the increasingly aggressive and innovative attack tactics employed by malware authors, who design malware to bypass defenses, evade detection, and resist efforts to remove it.

In fact, combating malware in an enterprise environment means not only locating suspicious programs on servers and workstations, but also detecting and interfering with the use of malware on the network. To win the battle for data security, institutions must discover malware propagation attempts and contain infections before they escalate into all-encompassing pandemics. Ultimately, in an enterprise setting, where thousands of diverse computers are loosely connected to perform diverse tasks, malware incidents must be treated as elements of a holistic security incident cycle. The cycle comprises four major phases: Plan, Resist, Detect, and Respond.

Step 1: Plan
As you design an approach to resist, detect, and respond to malware enterprisewide, begin by understanding the threat landscape relevant to your computing environment. This process involves reviewing what infection vectors you're likely to encounter. For instance, common approaches for malware to find its way onto systems include:

  • Vulnerabilities in client-side software on workstations.
  • Vulnerabilities in network-accessible software on servers.
  • Social engineering techniques, which often are part of malware-propagation tactics.
  • Removable media, such as USB keys.
  • Weak passwords of network-accessible accounts.

Which of these infection vectors are likely to be most dangerous to your organization? What technologies and procedures can you implement to prevent malware from propagating through these vectors? These are some of the questions you need to answer when designing your anti-malware architecture.

Next, consider the activities malware might undertake once systems in your enterprise have been infected. For example, common capabilities of malicious programs include downloading updates and instructions, collecting and sending out sensitive data, and propagating to other systems. What measures can you take to make it difficult for malware to perform those actions? It is important to hone your plan to detect and interfere with these activities not only at the end-point level, but also on servers, on internal network devices, and at the network perimeter.

Another key consideration: You probably won't have the budget to protect all information resources with the same rigor. Keeping financial limitations in mind, catalog potential malware targets (such as your data) across the enterprise and prioritize them by sensitivity, privacy, or any other measure relevant to your organization. Then design your malware security architecture accordingly. Focus on IT resources that process, store, or transmit the most critical data. Don't forget to incorporate into your design not only preventative security controls, but also measures for detecting malware and responding to the associated security incidents.

Once the plan phase is complete, the output often is a set of architectural blueprints, product recommendations, configuration procedures, training plans, and security policies that guide the enterprise through the rest of the security incident cycle.

Step 2: Resist
In the fight against malware, one might say that the best offense is a good defense: That is, when implementing the policies developed in the plan phase of the security cycle, institutions must take steps to resist malicious software attacks in the first place.

When it comes to protecting a single system from malware infection, the road map is usually clear. Common tasks include:

  • Install and maintain a modern anti­virus suite.
  • Lock down the configuration of the operating system.
  • Control what software is installed and allowed to run.
  • Restrict outbound and inbound network access.
  • Protect Web browsing activities.
  • Limit user account access and minimize user privileges.
  • Keep up with security patches.
  • Enforce change management practices.
  • Identify, investigate, and respond to anomalies.

While implementing these measures for a single computer is quite achievable, doing so for thousands of systems across the enterprise is a monumental challenge for most organizations. There are a variety of issues that factor in at the enterprise level:

  • The diversity of business requirements imposed upon systems: The variety of configuration and usage options across multiple users and departments makes it hard to establish a consistent set of security controls.
  • The geographic distribution of systems in large enterprises, especially those that employ laptops: Security administrators have a hard time protecting systems if IT cannot connect to them or if the systems access the network from various locations.
  • The difficulty of taking actions that span multiple systems: It's relatively simple for the security administrator to execute commands and review activities on a single host, but remotely controlling thousands of systems presents logistical and scalability challenges that are difficult to overcome.

The solution to all these challenges: Deploy some form of an enterprise management system (EMS). EMS is software designed for collecting inventory data, remotely executing commands, managing applications, and controlling the configuration across many systems in a scalable manner--making it possible to resist malware infection across the enterprise at the system level. Among numerous commercial EMS tools are Symantec Altiris, Novell ZENworks, and Microsoft System Center Configuration Manager. And for Microsoft Active Directory environments, the great news is that many EMS capabilities are already built in to the Group Policy functionality.

Keep in mind that resisting malware must take place not only at the system level, but also at the network level. In many cases, network security measures that enterprises have already deployed as part of their overall security architecture can help in the fight against malware. For example:

  • Restricting traffic from less trusted networks (e.g., the Internet) to the more trusted network, making it harder for malware to spread to vulnerable systems.
  • Restricting Internet-bound traffic by controlling allowed network ports and blacklisting connections to risky IP addresses and domains, making it harder for malware to exfiltrate data, update itself, or otherwise communicate with the attacker.
  • Restricting what systems are allowed to plug directly into the internal network by using network access control (NAC) technologies, limiting the risks posed by highly vulnerable or infected hosts.
  • Restricting how data can be transmitted from systems using removable media and the network by using data leakage prevention or similar technologies to complicate the ability of malware to transmit sensitive information to the attacker.

Of course, it's not realistic to expect that even the most robust set of controls will prevent all malware infections. Your ability to rapidly discover the presence of malware--and respond to it--often will affect the repercussions of the incident.

Step 3: Detect
The sooner you can discover the presence of malware in your enterprise, the sooner you can react and, hopefully, limit the spread of malicious code before the infection finds its way onto many more systems. Enterprises without mature anti-malware practices tend to rely solely on antivirus tools to spot malware. This may be a good start, but antivirus software is far from being the only security mechanism we need to discover and resist malware infections. Gone are the days when detecting malware by static signatures was effective, and the approaches to identifying malicious programs using behavioral and heuristic techniques are still in need of improvement. As the result, malware authors often are able to design their creations to avoid being detected by antivirus tools.

In order to more effectively protect systems enterprisewide, institutions must employ a variety of other means of identifying and tracking malware:

  • Use change detection tools to discover unauthorized modifications to the file system, network device configuration, or application code.
  • Educate end users on how to observe the signs of malware and how to report potential incidents.
  • Train IT personnel to perform an initial survey of a potentially infected system to assess whether it has been compromised. (Click here for a reference.)
  • Review security event logs to identify suspicious activities such as failed access attempts.
  • Employ intrusion detection systems to identify signs of malware in inbound and outbound network traffic.
  • Examine NetFlow data to spot anomalies in network traffic or attempts to connect to known malicious hosts (the Sguil and Argus tools can assist with this and related tasks).
  • Look at DNS logs to identify internal systems that attempt to resolve known malicious domain names. (For a script that can help, click here.)

Malware investigations might begin with the review of a single system, allowing the security administrator to formulate the signs of infection--called indicators of compromise--that can help locate malware elsewhere in the enterprise. Using this information to locate additional infected systems might involve examining network traffic or looking at the configuration of numerous systems throughout the enterprise. A free tool that can examine a system for custom indicators of compromise is YARA. EMS products also can assist with this task, as can specialized malware discovery and response tools, such as Mandiant Intelligent Response, F-Response Enterprise, and HBGary Responder.

Step 4: Respond
According to the National Institute of Standards and Technology's Computer Security Incident Handling Guide, responding to a confirmed malware incident involves three key steps: containment, eradication, and recovery. The execution of these steps should be driven by the guidelines the organization defined during the plan phase of the security incident cycle.

Containing malware involves efforts to inhibit its attempts to spread or compromise additional data. Understand the scope of the infection by reviewing the data collected during the detect phase of the cycle, and perform additional investigations where necessary. If malware is spreading with the unwilling assistance of employees--for instance when they click
a particular link--provide them with instructions regarding what they should or should not do in this situation. If malware is targeting specific services, temporarily disable them until you can address the relevant vulnerability. You may need to disconnect affected systems from the network or, in some cases, disconnect whole subnets. If you need to reboot or shut down a system, first take a snapshot of its memory for future analysis. Make a trustworthy backup of any file before removing it from the infected system, in case you need to refer to it later in the investigation.

Eradicating the infection involves removing malware artifacts, restoring from backup, or rebuilding the relevant systems. Staying in contact with your antivirus vendor can help you obtain a set of malware signatures for detecting and--at least partially--disabling malware in your environment. Modern malware can embed itself deep in the OS, and may be used by the attacker to install additional tools and take a variety of malicious actions on the compromised host. As a result, incidents where you can reliably remove malware without rebuilding or restoring the host are very rare. However, knowing how to disable malware can buy the enterprise some time during the incident response process. Use this time to lock down systems, patch vulnerabilities, and reconfigure relevant IT infrastructure components.

Recovering from the incident focuses on resuming normal operations of the affected IT infrastructure. Keep an eye on the restored or reconfigured systems to confirm that they no longer exhibit the signs of infection, and assess what temporary containment measures can be removed. Recovery from a malware incident also involves collaborating with non-IT colleagues, such as public relations and legal teams, to take the necessary actions with respect to the organization's constituents. The recovery step often requires a continual examination of aspects of the enterprise's IT infrastructure to see whether additional signs of infection appear in areas that have not previously exhibited indicators of compromise.

After the incident is resolved, the response team needs to review its actions to determine how to improve its ability to handle future infections. It also needs to assess and adjust the relevant security components to see whether the environment can be made more resilient to such incidents. These actions complete the security incident cycle, bringing us back to the plan phase.

In the end, how the enterprise plans and executes its actions during all four phases of the security incident cycle will determine the success of its quest to combat malware.

The Security Incident Cycle

Malware is the tip of the spear that attackers often use to compromise an organization's IT defenses. On a strategic level, malware combat should be placed in the context of an institution's overall security incident cycle. The cycle, as was initially defined by security guru Richard Bejtlich, comprises four major phases: Plan, Resist, Detect, and Respond.

In the plan phase, the enterprise prepares for security incidents by understanding the
relevant threats, assessing systems' vulnerabilities, and designing a security infrastructure
and processes accordingly.

The resist phase encompasses the enterprise's efforts to avoid data breaches by making use of the architecture--the security program and associated tools--designed in the plan phase.

During the detect phase, the enterprise monitors its IT infrastructure, data transfer, and user activities to discover incidents as early as possible, with the expectation that the resist phase will not be able to prevent all malicious activities.

The respond phase mobilizes the enterprise's incident handlers in response to discovered anomalies.

comments powered by Disqus