Protecting Against Macro Viruses

If you can add code to a Project file, so can the people who write viruses. Viruses are self-replicating programs that can be embedded in executable files or document files by using macro code. When you open a file that contains a macro virus, the virus copies its code into the application’s default template, effectively becoming a global virus. From that point forward, every project you save in the application will be infected, meaning that every file you give to someone else on a disk or via the Internet will also contain the virus—not the best way to improve your popularity at work or home.

Macro viruses are a recent phenomenon because powerful application programming languages are relatively new. If an application isn’t programmable, there’s no way to create a macro; application programming languages that can create or save files open the door for code that can replicate itself. Put the two together, and you have an environment suitable for macro viruses.

The first macro virus, created in 1994, was for demonstration purposes only. Within a year, macro viruses created for other purposes were found “in the wild.” Fortunately, those early macro viruses were designed to embarrass and were, in the world of viruses, relatively benign. They’d ship humorous or nasty messages to a few of your Outlook contacts, or change the header or footer in a file to something you wouldn’t want to distribute at a meeting.

The damage a virus is designed to inflict is referred to as its payload. Some recent macro viruses have a heftier payload. For example, viruses that modify the Windows registry, or delete some or all folders from the default drive, are not uncommon today. These highly destructive viruses make us yearn for those good old days (just a few short years ago) when the typical macro virus payload was repeated display of a happy birthday message for someone you’d never heard of.

How to Protect Against Virus Infection

When you open a file in Microsoft Project, the program scans the file to see whether it contains macros. Depending on the security settings you’ve selected (discussed next), Project may display a message warning you that you’re opening a file with macros. Project does not, however, determine whether these are “good” macros or virus-infected macros. For that reason, you should install a good antivirus program on your computer. Without this protection, any infected Project file you open can do whatever damage it was programmed to inflict. With an antivirus program running, all files with macros will be scanned; and if the macros are found to contain virus code, the file won’t be allowed to load.

Tip 

Two of the best antivirus programs are Norton AntiVirus (www.symantec.com) and McAfee VirusScan (www.mcafee.com).

Understanding Digital Certificates

Another way to protect against potentially harmful macros is to accept only those macros that have been certified safe. The Microsoft Windows operating system supports the use of digital certificates (also called digital signatures) just for this purpose. These digital certificates are issued by companies such as VeriSign for use by software developers and individuals to certify the authenticity of the contents of a file, program, or e-mail message. Although anyone can obtain a digital certificate, a certain amount of information, such as a credit card number and verifiable e-mail address, changes hands during the application process. The company or organization issuing the certificate tracks the certificates, and can contact the certificate owner if software or files with their certificate include viruses.

This method isn’t foolproof. We have certificates and theoretically could, on a lark, send a few digitally signed files with nasty macros to our friends and loved ones—just before running off and disappearing into the wilderness. We could write virus macros that would run automatically when users opened the Project file, so we wouldn’t have to count on our recipients running them for us. This wouldn’t be fun for long, though (if it ever was). The recipients would know with certainty that we sent the files. We’d need to stay in the wilderness for a long time.

Configuring Project’s Security Settings

A digital certificate isn’t enough by itself to guarantee safety. You add a layer of security, however, when you designate a particular selection of digital certificates you’re willing to accept, which you do by managing Project’s security settings.

In Microsoft Project 2002, these security settings are accessed by choosing Tools Ø Macro Ø Security. This opens the Security dialog box, which has two tabs. The Security Level tab is used to set the level of security when opening projects with macros; the Trusted Sources tab is used to okay the running of macros from specific certificate holders.

The Security Level tab enables you to select from three levels of security, as detailed in Table 24.1:

Table 24.1: Project 2002 Security Settings

Security Level	Description
High	Only signed macros from trusted sources are allowed to run. Any other macros are automatically disabled.
Medium	You are prompted when opening unsigned macros, or macros from untrusted sources.
Low	All macros are allowed to run with no warning notices displayed.

For ultimate safety, you would select the High level; however, this level of security can be annoying at best, and crippling at worst, because macros created from others in your organization won’t be allowed to run. That is, unless you add them to the list of trusted sources on the dialog box’s Trusted Sources tab.

The least safe—and least recommended—option is the Low setting, which provides no protection at all. This setting is safe only if you don’t use Project in a workgroup or enterprise environment, and if you never exchange Project files with other users.

A more practical solution is to choose the Medium setting, where you have to give explicit approval to run new or unrecognized macros. This puts the control (and the responsibility) firmly on your shoulders, with no options withdrawn. When you set the Security Level setting to Medium and then open a file that contains unsigned macros, Project displays this message box:

You can choose to open the document with macros intact (click the Enable Macros button), which is an accepted course of action if you know for sure who created the macros and that the macros are safe. If you’re unsure about the source of the macro code, click the Disable Macros button to open the document without opening the macros.

It never hurts to click the Disable Macros button. Disabling the macros gives you an opportunity to look at them in the Visual Basic Editor without risk of infection. After you’ve clicked Disable Macros, you can look at the macro code in the Visual Basic Editor (see Chapter 27). Check the macro’s description (see Figure 24.3, earlier in this chapter) to see whether it was written by you or a coworker. If you know that the file is from a trusted source (with good virus-detection software on their system); or if you’ve just examined the macros, judged them satisfactory, and closed the file, click the Enable Macros button to load the project file and enable the macros.

Tip 

This raises yet another good reason to always enter your name and contact information when creating a macro. It gives other users less reason to delete the macro, and gives them a way to reach you if they’re still not sure.

Mastering the Opportunities: Managing Risk

You’ve probably figured out by now that we take viruses seriously. We run virus-detection software all day, every day, and we scan every floppy disk, Zip disk, and newly burned CD-ROM that leaves our office. Twice. We’re computer consultants, and we can’t afford to be remembered as the company that gave you a virus that wiped out your hard drive.

As a project manager, you’ll be sending e-mail and document files to communicate project information on a regular basis, which increases your exposure to viruses and the costs associated with spreading viruses to other users. Fortunately, most organizations include some antivirus software on their workstations. If you have antivirus software, check with your network administrator to see how often the software is updated. The virus definitions used by antivirus programs must be kept up-to-date to protect against the dozens of new viruses that are created every week; antivirus software that hasn’t been updated in six months is relatively useless.

Now, to take a little edge off all this doom and gloom, you should know that the chances of contracting a macro virus via a Microsoft Project file is relatively low. That’s because of the nearly 10,000 macro viruses identified to date, nearly 80% of them used Microsoft Word—not Project—as a host. There’s a simple reason for this, and it isn’t because Word is easier to write viruses for. (It isn’t; Word and Project share the same VBA language.) It’s because Word has such a large number of users that it’s a natural target.

That’s not to say that Project viruses don’t exist—they do. The first virus designed specifically for Project was reported in October 1999. That virus, fortunately for all, was a low-risk, relatively harmless virus that moved back and forth between Word and Project. Other Project viruses could be more destructive, though. The potential exists for contracting a Project virus that reassigns resources, changes task durations, and otherwise destroys the integrity of your Project data.