14.2 Malicious Mobile Code Defense Plan

Team-Fly

---

 

	Malicious Mobile Code: Virus Protection for Windows By Roger A. Grimes Slots : 1
	Table of Contents
	Chapter 14.  Defense

---

14.2 Malicious Mobile Code Defense Plan

This part of the chapter will discuss how to create a Malicious Mobile Code Defense Plan and the steps and processes that it should contain. This plan should be part of the organization's larger Computer Security Defense Plan , along with Acceptable Use and Physical Security policies and procedures.

14.2.1 How to Create a Malicious Mobile Code Defense Plan

Here are the steps to create a malicious mobile code defense plan.

14.2.1.1 Get management to buy in

Whatever the outcome of the malicious mobile code defense plan, it will take time, money, and people to implement it. Make sure you have management buy in before you head down this road. Nothing hurts worse than building a good plan, but being denied the money and resources to make it happen. Some important justifications for a good defense plan are

• Overall decreased costs

• Protects company credibility

• Increases end users' computer confidence

• Increases customer confidence in IT staff

• Decreases risk of data corruption

• Decreases risk of stolen information

You need a management champion to help things go smoothly. A good way to get that is to quantify the potential losses in relation to the estimated costs of a good approach to defense.

14.2.1.2 Pick a plan team

Pick the people you will need to create and implement a defense plan. You will need someone on the team to spearhead the whole effort operationally. Include folks from the help desk, people who assist with laptop and remote connectivity issues, programmers, network technicians, security members , and even think about including the super-users of any large end user groups. If you get their buy-in during the planning process, end users should be more willing to help the team accomplish their goals. The size of your team depends on the size of your organization, but it should be small enough to manage in a reasonable timeframe.

14.2.1.3 Pick an operational team

Decide early on who will be the team members to implement the hardware and software mechanisms to prevent malicious mobile code solutions, who will keep them updated, and who will be involved during an malicious code outbreak.

14.2.1.4 Take a technology inventory

You can't put an antivirus management plan into place until you take an enterprise inventory. Table 14-1 shows a basic inventory list. Besides noting the number of users, PCs, laptops, PDAs, file servers, email gateways, and Internet connection points, record the types of desktop operating systems, major types of software, remote locations, and wide area network connectivity platforms. All of this data will allow you to wrap your arms around what it is you have to defend. Your solution will have to consider all of these factors.

Table 14-1. Computer inventory

Identifying information	Function/Operating system
Serial #	Machine name	Username	Location	PC	Server	Other
W345349	Account1	BHoward	Accounting	Win98
Y324876	IT01	THyman	IT-PHR		Win 2000 Pro.
R211288	IT03	WCohn	IT-GKR		Win NT 4.0
S100045	Exec1	BThompson	Corporate			Linux

14.2.1.5 Determine plan coverage

Now it's time to discuss the objectives of the plan. Whom will it cover: corporate offices, field offices, remote users, laptop users, thin clients , etc.? What type of computer platforms is it going to cover: IBM-compatibles only, Windows NT, Windows 3.x, DOS, Macintosh, Unix, Linux, file servers, gateways, email servers, or Internet border devices? Will it cover all computer devices or just the devices most at risk? Whatever the conclusion, it should be written up at the beginning of the document and the plan should be built to protect those areas.

14.2.1.6 Discuss and write the plan

Your plan needs to spell out in detail what and where antivirus tools will be deployed, what assets will be protected, how the defense tools will be deployed and when, how updates will be done, how to define a communication pathway , end user education, and a rapid response team procedure for dealing with outbreaks. You can use the outline of this chapter as a plan skeleton to begin writing. The largest sections of your plan should detail antivirus software use and placement, and the steps needed to properly secure each PC. Section 14.2.2 will cover this in more detail.

14.2.1.7 Test the plan

Before beginning wide-scale deployment to your production environment, make sure to test it on a bed of test servers and workstations. If everything is successful in the test environment, start limited testing in your production environment. Often this includes deployment to one entire department in your organization, followed by spot deployment in other areas. The intention is to test tools and modifications across a wide range of workstation and network types. I've seen much worse damaged caused by well-meaning IT staff trying to deploy protection tools than by the rogue programs they were trying to prevent. Make changes to your strategy as deemed necessary.

14.2.1.8 Implement the plan

Discussing and writing the plan isn't the hardest part of this process, implementing it is. Taking what you've put on paper and deploying it to hundreds or thousands of workstations takes money, people, and time. You must decide what to buy and where to start to get the most protection for your efforts. A good strategy is to implement antivirus tools at email or file servers first, followed by installs and modifications made to end user workstations. Laptops and remote field offices can be covered in a second round, and can benefit from lessons learned from the first round of deployments. A checklist, like Table 14-2, needs to be maintained so every inventoried asset that needs protection gets it. Without a centralized list it is easy to miss computers.

Table 14-2. Modification checklist

Identifying information				Protection steps taken
Serial #	Machine name	Username	Location	Installed desktop AV	PC modifi-cations	OS Patch
W345349	Account1	BHoward	Account	P	P
Y324876	IT01	THyman	IT-PHR	P	P	P
R211288	IT03	WCohn	IT-GKR	P
S100045	Exec1	BThompson	Corporate		P	P

14.2.1.9 Provide quality assurance testing

You want to do lots of QA testing of tools and procedures during and after the implementation. First, test that they are doing their job. This can mean sending a virus test file or some other sort of test against a protected system. Don't use anything that would cause widespread problems if it got loose. Many companies use the EICAR test file. Test the mechanisms for software and signature database updating. Do spot checking around the company to make sure the deployment team protected all the assets they were supposed to.

EICAR Test File

You can use the EICAR antivirus test file (http://www.eicar.org) to do a limited test of your scanner. This file is nothing more than 68 bytes that most antivirus vendors have agreed to identify as the EICAR test file. It can be used to verify that a newly installed or updated scanner is working well enough to identify a test scan string. Some larger organizations send the EICAR file daily to protected servers and gateways to verify proper operation. If a notification message isn't received after sending the test file, managers know that particular server or device is not protected.

14.2.1.10 Protect new assets

Lastly, put a policy and procedure into place to protect new computers. Often deployment teams are able to come together to protect all the assets as defined under the original plan, but fail to remember to modify new computers a month later. Random checks of new PCs should be done to make sure policy and procedures are working.

14.2.1.11 Test Rapid Response Team

A Rapid Response Team is used during malicious code outbreaks. Test the rapid Response Team with a preannounced pretend outbreak. This gives everyone a chance to practice their roles, test communication systems, and works out any kinks. In my experience, the little problems found in the practice test tend to grow during a live event if left unaddressed. Depending on whether or not you have periodic outbreaks to review performance against, you should test the team a few times per year and after operational changes.

14.2.1.12 Predefine a process for updating and reviewing plan

No security plan is static. Software, hardware, and operating systems always change. User behavior and new technology will allow new risks to enter your environment. Your plan should be considered a "living document," and a predefined process to periodically review and evaluate its effectiveness should be written. Immediate reviews should be conducted when a new risk appears or when the effectiveness of the plan begins to wane.

14.2.2 The Plan

Now that the team is assembled and your environment is documented, it is time to write the plan. Your malicious mobile code defense plan has to address all the ways malicious mobile code can enter the company. Most rogue programs enter primarily through Internet email systems. However, viruses, worms, and Trojans, can also enter as macro viruses from documents on disk, downloaded off the Internet, from an instant messaging client, or from infected diskettes. Fifteen years ago, scanning incoming diskettes and disabling floppy booting was enough. Today, you have to consider diskettes, the Internet, email, laptops, PDAs, remote users, and any other mechanism that allows incoming data or code to enter your protection domain (see Figure 14-1). Your defense plan even needs to include how to deal with hoax virus messages.

Figure 14-1. Potential malicious mobile code entry points

14.2.2.1 Remember to address foreign computers and networks

In most corporations foreign ^[1] networks and computers routinely attach to the company's already protected resources. If you have to worry about infecting other company's computers, it is only fair that they take the appropriate measures to minimize infecting your domain. Vendors, third parties, and business partners attaching foreign computers or networks to your own should be required to follow a minimum set of rules, and sign a document attesting to their understanding. Sometimes the efforts and tools applied in the company's defense plan can be shared with foreign computers and networks, or it can be as simple as requiring an updated antivirus scanner to be used.

^[1] By foreign, I mean computer assets not owned by a company or under your direct control.

14.2.2.2 Plan core

The following three goals are the plan's cornerstones :

• Use a reliable antivirus scanner

• Modify your PC environment to prevent malicious code from spreading

• Use other tools to provide a multitier defense

Using a reliable, up to date, antivirus scanner should be the cornerstone of any malicious mobile code defense. Antivirus scanners are great at protecting computers by detecting and removing malicious mobile code and every company should use them. However, it is a mistake to totally rely on the antivirus scanner. History has proven again and again that a scanner cannot and will not stop everything. You must assume that malicious code will get by your antivirus defenses, and take proactive steps to minimize its impact. If done correctly, malicious mobile code will not be able to function at all on a protected PC. Lastly, you should consider other types of defense and detection tools to protect your environment and to track down exploits quickly. I will cover all three of these defense tenets in detail in this chapter.

14.2.2.3 Deployment

Your plan should detail the human resources needed to implement the policies and procedures. It usually takes the coordinated effort of many skill sets to deploy all the malicious code tools and modifications. Network administrators will be needed to test and install software on file and email servers. Teams of hardworking technicians will be needed to modify the local workstations, unless you have sophisticated deployment tools. You need to calculate how much time each person will spend testing and installing software and create a deployment schedule.

14.2.2.4 Distributing updates

Once the malicious mobile code defense tools and modifications are implemented, how do you keep them updated? Many antivirus tools allow you to download updates to a central server in your network that then pushes updates to local workstations. Workstation modifications can be made manually to one PC at a time, or using centralized login scripts, scripting languages, batch files, Microsoft SMS, etc. Avail yourself of any automated distribution tools, although always test big updates manually first. Large organizations with a variety of desktops and wide area network types always end up using a variety of methods , including automated distribution tools, CD-ROMs, diskettes, mapped drives , and FTP. Use the tools that work for your environment. Also, hold people, staff, and end users accountable for making sure updates are applied. There is always one team leader or department that would rather forget than install.

14.2.2.5 Communication plan

Central to a defense plan is communication. End users and automated alerting systems should notify defense team members when a malicious code outbreak occurs. Team members need to contact each other to assemble the team. The team leader needs to notify management. Someone on the team should be designated as the primary contact between the company and the antivirus vendor. A chain-of-command process should be predefined so that status updates can be passed from the team to individual end users.

In a typical plan, each team member that will be responding to an outbreak emergency (the Rapid Response Team) should be responsible for communicating with particular department or division heads. The contacted department leader then has the responsibility for informing employees under his control. Build in feedback mechanisms so end users and departments can communicate back to the team. Define clear roles and responsibilities. This part of the plan should not be assumed.

14.2.2.6 End user education

Although you should write your plan as if end users ignore all precautionary advice, make a concerted effort to inform and educate end users. Your education component should include a brief introduction to the world of malicious mobile code. It should talk about viruses, worms, Trojans, malicious emails, and rogue Internet code. Employees should know that downloading software from the Internet, installing fun-looking screensavers, and running joke executables are all large risks. The educational material should talk about the associated risks and the efforts the company is taking to minimize those risks. It should include the steps every employee should take to minimize the spread of malicious mobile code.

Let end users know that only authorized software should be used on company computers. Software should not be downloaded from the Internet, brought from home, or installed from sources not previously authorized. And although you would think it goes without saying, users should be reminded to report malicious code outbreaks to the appropriate person or department. End users should be told that breaking the rules can result in a disciplinarian action. Users should be given documentation and required to sign a form indicating their understanding. This form should be filed in the employee's personnel record. Also a process should be put in place so that new hires are educated before they receive computer access. In most environments, the educational material is included with their hiring package.

14.2.2.7 Rapid response plan

Every plan should define the steps team members should take in the event of a malicious code outbreak.

14.2.3 Rapid Response Plan Steps

Normally, the defense tools implemented should protect your environment, but every now and then a new type of malicious code will slip by or an unprotected machine will spread an already known threat. In either case, you now have a widespread problem. Your plan should explain what happens if multiple infections become an outbreak. For example, 10 or more machines within 10 minutes should be considered an outbreak and result in alerting the Rapid Response Team. Anticipate occasional outbreaks and implement a plan to deal with the threat quickly and efficiently . Here are the steps that should be followed in an outbreak:

Report incident to a leader

No matter how the outbreak is first noticed, the first team member to hear about the outbreak should alert the team leader and then alert the other team members. The communication method should be fast, reliable, and not prone to malicious code interruption. For example, if you routinely send critical pages to team members via an Internet email address gateway, assume the email gateway will be clogged with malicious code emails. Plan an alternate communication method. Some teams manually dial a list of pager numbers if an email threat is involved, others use cell phones or HTML-based email.

Collect initial facts

Arriving members of the team should begin to share what they know about the malicious code program. Is it arriving via email? Do they know where it first appeared? How long has it been spreading? Does it modify local files? What type of malicious code program is it? What language is it written in? Begin to collect the facts needed to get an introductory understanding.

Minimize spread

After the initial facts are collected, immediately take steps to minimize the spread. If it is an email worm this may involve disabling the email servers and/or Internet access. If malicious code is actively modifying or destroying files on a file server, disconnect users and disable logins. If the attack is bad enough, consider powering down servers and workstations. I've been in multi-state, mission-critical environments with tens of thousands of computers, and had management forbid powering down the servers. Any cleanup can be done without downing servers, but it will take much longer. In the case above, clean up took two weeks instead of two days. If faced with a similar circumstance you should allow senior management to decide whether to minimize downtime or minimize service interruption. Also, make sure you keep track of what servers and services are being disabled so they can be brought back up later.

Don't trust end users to leave a system alone in lieu of disabling access to it. Someone will always pretend they did not get the message to stay out of the system or say they were logging back on to see if the problem was gone.

Let end users know about the new threat

Make sure the word gets out to all end user departments about the malicious code outbreak. Posting crude paper signs on entrance doors and in common work areas about the problem and what the user should do is a good way to notify users. If the malicious program has spread from your company to other companies, consider communicating with them as well. With email worms though, by the time you send a warning, it is usually too late to stop them from getting infected.

Notify not only affected departments, but unaffected ones, too. That way unaffected departments can be on the lookout for the early stages of infection and warn their users not to open certain emails, etc. Let end users know that you are working on the problem and that you will contact them when it is safe to get back into particular services and servers. Also, be sure to contact management so they can know what is going on.

Collect more facts

By now you should have the bug somewhat contained and taken the steps to prevent further damage. The Rapid Response Team should have gathered and have discussed the problem. New malicious code programs should be submitted to an antivirus vendor for analysis. Finding out who isn't infected is as important as who is. If every machine in a particular department is infected but one, find out what that person or machine didn't do (e.g., open the infected email). There might be a particular workstation component that prevented the bug from spreading. If the malicious program should have been prevented by your defense tools figure out why the bug got by.

Determine the extent of the damage. How widespread is it? How many PCs? How many departments hit? What did the rogue program do to the PC? Did it drop off other files, rename files, overwrite files, make registry changes, or insert itself in the startup areas? Usually I'll run Find Files or Folders on the PC to find out what files have been modified in the last day. Usually if a virus or worm hits, you'll see the new suspicious files right away. Then I'll check the various startup areas looking for suspicious inserts . Next, I will use NETSTAT -A to look for suspicious Internet connections. If I find suspicious files, I will usually do a quick EDIT on them to look for any revealing statements. Then I'll compare my findings with other members on the team checking other PCs. Did the program consistently do the same thing? Do the dropped files have the same name every time? Does the subject of the infected email remain the same? Are the system modifications consistent between computers? Collect and log all the evidence.

If you have the appropriate skill set on your team, disassemble the malicious program to learn everything that it has done. The source code of many of today's VBScript worms can be read and at least moderately understood by any programmer. Without this step or detailed information from an antivirus vendor, you cannot be 100 percent sure of what the bug has done.

Make and implement an initial eradication plan

Take what you have learned and implement a methodical eradication plan. For example, with most email worms, first delete all infected emails ( EXMERGE on Microsoft Exchange server is a useful tool). Remove or replace any damaged or infected files as well. Suspect files should be moved to a quarantine area for later analysis. Using a centralized login script, you can then include a batch file program that searches for the existence of the rogue program, deletes it from the PC, and repairs the damage.

Consider making a complete copy of a compromised system for later analysis before you begin the cleanup. Be sure that well-meaning technicians don't delete all copies of the rogue program, leaving you nothing to look at so you can find out what the rogue program did. Deleting all copies of the rogue program complicates the clean up process, not vice versa.

Always run the clean up program against a test suite of machines, first making sure the cleanup program does not cause more damage. Next, run the eradication program against a few regular machines in different areas. Again, verify that the rogue program is eradicated, that the program cleans up damage, and that no further damage is done. Only now send the cleanup program out to the masses. Use your predefined communication mechanisms to alert end users and to give additional instructions.

Verify that eradication steps are working

Send out members of your operational team to verify that end user machines are being appropriately cleaned and monitor communication channels for problems. Sometimes at this point I have found out that there is something the team missed during the initial analysis stage. If this is the case, the cleanup program should be appropriately modified and redistributed to all affected users. Communicate the cleanup status to operational staff and end users.

Bring disabled systems back online

As they are cleaned, bring disabled systems back online. In my experience, as soon as a system is enabled, users will begin logging into it. Use your checklist of systems you disabled so that you can remember to enable everything. Remove paper signs that warned users, and communicate to end users that they can use their computers in a regular manner. Let them know if any systems remain offline.

Be prepared for a reoccurrence

Be prepared for the rogue program to recur, and tell your end users the same thing. Usually the longer it takes to notice the initial attack the more likely the problem will be back. In the early days of DOS boot viruses, it could be months to years before the company noticed it was infected. By then, infected diskettes were throughout the company and sure to be showing up again. Email worms are the same way. Catch them early and they don't get a chance to spread far.

Now is the time to relax a little. The Rapid Response Team can disassemble and go back to their normal duties .

Determine public relations impact

Discuss the outbreak's impact on end users, the company, operations, external customers, and business partners. If the rogue program spread from your company to other companies, now is the time for apology letters or emails. Reassure that the problem has been fixed and prevented from reoccurring again. Notify any required reporting agencies, and decide if law enforcement needs to be involved. Also consider an appropriate public relation's response if the news media calls, the text of which should already be documented in your plan.

Do a more thorough analysis

Now that the crisis is over, do a more through analysis. By this point you should have a full understanding of what the rogue program did. Either your team disassembled it or the antivirus vendor you sent a sample to was able to tell you. Use a more thorough analysis to repair remaining damage. Determine if your defense plan or tools had any flaws that allowed the rogue program to spread, and if it did fix it. It can also be helpful to document any trends, such as one type of malicious code becoming more popular than another. The trend will help you modify your plan appropriately.

Most antivirus software keeps a history log. You can use collected statistics and metrics in future budget talks to justify the expense and effort of a security program.

All malicious mobile code defense plans should include using a reliable antivirus scanner. The following sections detail how to pick a good antivirus scanner and where to install it.

---

Team-Fly

Top