White Paper: Establishing virus prevention policies

Feature

White Paper: Establishing virus prevention policies

How do you make anti-virus policies work? Symantec takes a look at the issues companies need to consider

How is an old virus able to plague your organisation? Obviously, older viruses have had more time to multiply and are consequently more common than new strains. Older viruses generally use more primitive techniques for escaping detection. It is theoretically simple to detect and remove a virus that has been around for a year or more.

Managers in such organisations have difficulty believing that the virus in question is easily preventable or easily removed. If it is so easy to prevent, why haven't their policies and programs done just that? If easily removed, why has their vendor recommended deleting infected files? If it is so old, why does their trusted anti-virus software tell them it is a "new variant"? The answers to these questions are simple but painful to hear: their policies or their products have failed.

No one wants to believe their product has failed on an easy virus. Nearly every day we hear that vendors have told users that the virus they have is "new". We get a sample and take a look. Usually, the virus is two or three years old. This white paper is not about the failure of anti-virus products. It focuses on policies, although policies are always tied to people and products.

The central concerns of any policy maker are enforceability, expense and efficacy. Policies that are unknown, complex or unpalatable will fail. Policies that can only be implemented with great expense will fail as will those that are not efficacious.

The problem of viruses in organisations adds a new degree of difficulty for the policy maker. While policy makers should be able to judge the enforceability and expense of an anti-virus policy, they are rarely able to judge its efficaciousness. Anti-virus policies can seem to work (to the policy maker) when either there is no virus or when the virus incidents are not reported to the policy maker.

Policies are intended to be practical advice for what we can do with what we have. Our imagination on how to prevent viruses has always been restricted by the limitations of our software. When all your entire organisation owned was a virus scanner, all you could recommend was that users should scan. Traditional policies do not differ in their endorsement of scanning, only in their recommendations for how often scanning should occur.

You need a strong and clear policy for your organisation to provide a deterrent and to strengthen your hand with those who ignore policy.

Policies alone don't solve problems. In fact, they sometimes just create them. The world's best-written policy is without value if the people who need to follow it are not aware of it or are not motivated to comply with it. You may have an administrative requirement to create a security policy. An internal or external audit may have suggested its creation, or senior management may have reacted to an article in the press regarding a security breach and proclaimed: "Don't let this happen here." You may have some regulatory or statutory requirement for such a policy or you may have simply decided that it just makes common sense.

Your security policy may focus on information protection, recognising that information security is a business issue, not a technical issue. Information is a corporate asset with a tangible value. As corporate reliance on computer systems increases, information becomes both a strategic asset and a tactical asset. It becomes a strategic asset from the perspective that knowledge of processes, formulas, research and development provides long-term stability and growth. It becomes a tactical asset from the perspective that knowledge of customer needs, marketing data and systems designed to respond to rapid change in these areas provide an organisation with an enhanced ability to outperform the competition.

Policy creation

Before you begin to write a security policy, conduct your own risk assessment, identify the assets you want to protect and determine what you want to do to protect them. You may also want to spend some time conducting company-wide discussions on topics such as:

Information ownership: Whoever owns the information has the duty to care for it.

Valuing our information: Until we recognise the value of information, we cannot be expected to show proper care for it.

The value of privacy: To what extent do users desire privacy? Do they expect it? Is the right to privacy something on which our organisation can agree, so that the organisation can develop policy that ensures users' rights are protected?

The ethics of break-ins: Do we, as an organisation, find computer break-ins to be immoral, serious or silly? As you explore this issue, perhaps by using imaginary case studies and ranked comparisons, you may discover considerable disparity in staff members' attitudes toward appropriate punishment for various offences. Group discussion helps bring out these attitudes and ensures that policy is written to fit your staff's beliefs.

Purpose

A good policy statement should:

Support the organisation's goals.

Describe your overall network security program, including ongoing maintenance and enforcement.

Itemise the results of your risk assessment, including the threats you are responding to and the safeguards you propose.

Define responsibilities for the implementation and maintenance of each safeguard.

Define appropriate and inappropriate behaviour for users in such a way that the document can be used in court if security violations occur.

Policy is intended as a change agent. While it cannot prevent tornadoes, floods or lightning. But it can provide a foundation for procedures that minimise the impact of such calamities when they occur. Thus, it can be your organisation's policy to back up important information carefully and regularly, and store it in a secure, off-site location.

Assuming your policy addresses those things that should and can be changed, you must then figure out who will help write the policy, and for whom it is to be written. The traditional approach is for a security enthusiast (that is, someone with a bit of responsibility but little authority) to draft it and then try to sell it to top management. Management, in turn, is supposed to enforce it by making users comply. This approach has two problems: top management often doesn't buy it; and when they do, they don't know how to sell it. It might be just as effective to take your ideas to users, let them discuss them and let them write the draft policy. Such a draft they can accept is theirs even though management has not yet approved it. If management later endorses the policy, good.

A twist would be to not have users write policy for users or management to write policy for users, but for users to write policy for management. Such a document would describe what was needed that couldn't come about merely by users changing their own behaviour. It could include shopping lists of equipment needed, staff roles and responsibilities in need of expansion, and ideas for reorganising departments to build greater morale, cohesion and therefore security. Don't try this experiment at home, of course. Just because it works in other countries (like Japan) doesn't mean it works here.

Audience

After upper management and users have thoroughly discussed the proposed policies, you should consider rewriting and expanding your initial policy statement, creating several documents. Each of these documents can be aimed at a different audience and can range in formality from a series of memos to a "How to Implement It" manual. Whatever the format, the purpose is to provide practical how-to advice. You certainly need a series of such memos (or a manual) for users, a series of memos for network managers and another set of documents for managers.

Content

What should go into your policy? Here are some ideas:

Which information resources to protect

Which software to allow on employees' PCs

What happens when unapproved programs and data are detected

Internal sanctions and prosecution guidelines

Who the policy affects

Who developed the guidelines

The highest authority who has approved these guidelines

Who has exactly what authorities and privileges

Who can grant authorities and privileges

Procedures for providing or revoking security privileges

Expectations and procedures for reporting security violations and criminal activity

Specific management and employee responsibilities for making security happen

Explanations of the importance of the policy (a user base that understands the reasons for a policy is more likely to follow it)

Effective date and revision dates

Who enforces these guidelines and how they do it

Style

Use colloquial language. Today, employees at all levels of organisations are apt to be using computers. Don't assume your reader has mastered Webster's Unabridged Dictionary. Don't be chummy and don't plead, whimper, whine or grovel. Your policy simply explains the deal, explains the consequences for breaches and lays out the procedures for implementing each policy item. Be brief. The more words you write, the fewer are read. Remember KISS: Keep It Short and Simple (or Keep It Simple, Stupid).

Policy implementation

Here are some specific suggestions for your ongoing support program:

Good security policies depend on the knowledge and co-operation of the users. This is just as true of security against viruses as it is of policies about password management

Policy idea: No policy is considered to be implemented until users are trained in the skills needed to follow the policy

Security requires more than knowledge. It requires action. All users must know how to act when confronted with a breach or possible breach

Policy idea: All users should know whom to call if they have questions or suspicions, and should know what to do and what not to do, to minimise security risks

Users should be encouraged to feel that security measures are created for their own benefit, rather than for no rational reason

Policy idea: Users help set policy. Invite them to do so in open meetings to discuss policy proposals and provide them with the opportunity to comment in writing on policy drafts

If you want to present your policies only once, hire elephants. Because users are humans, they forget policies. If users don't have a 12-month retention span, then hold a user-level policy review more often than once a year

Policy idea: Provide policy refreshers in the form of posters, email, memos or staff meetings whenever you suspect a lapse in awareness

New employees don't know what long-term employees know about your policies. You must inform new employees about your policies. If you just had a user briefing yesterday and today you hired a new employee, you need to do a security policy orientation for the new employee

Policy idea: Fully and carefully brief all new and temporary hires on your security policies and procedures

For some users, the elevator doesn't stop on every floor. Just because you can quickly grasp the important points in your 200-page security policy doesn't mean that anyone else can. Break up your policy document into digestible bites and feed your users one bite at a time. Twelve messages a year is more digestible than one big one

Policy idea: Provide users with policy guidance in manageable units

Even when users understand a policy, they may be justifiably concerned about how to implement it. Provide model implementation procedures and examples with every policy that you have. As questions arise, record them (along with your answers and explanations) in the policy document. Share your updates with users

Policy idea: Always couple policy with model procedures and examples of how to implement

Some folks seem intent on getting us to worry sick about the damage we could cause to our computers. The backs of many floppy disk jackets, for example, list numerous threats to the poor floppy. In fact, users do not need to protect their floppies from fruit flies or asteroids. Follow Emerson's advice: Simplify! Be sure your policies focus on the truly important dangers: those that have some fair chance of occurring and those that pose some fair risk if they occur

Policy idea: If you've been developing policies for the last 100 years, throw out half of them. Cut down your security policy documents to about two dozen topics or less. Summarise each of the main policy points in a sentence or two

So whom do we call? You've got to be sure that your users know just whom to call for each of the problems the organisation intends to solve

Policy idea: Distribute postcards, stickers or other printed matter indicating who is dealing with what sorts of problems, their phone numbers and their office locations. Ask users to keep these numbers handy

We cannot know whether users have agreed to accept and follow a policy by notifying users of the policy merely by email or memo. We cannot even know if the policy was received and understood

Policy idea: Users are required to sign and return one copy of every policy statement they are asked to follow

Assigning responsibility without requiring accountability is a sure-fire formula for disaster. Your employees must understand that they are held personally accountable for complying with the information security policy. To be sure that everyone knows what your policies are, send (or hand-deliver) a copy to each and every employee. Include an acknowledgement and consent form with the document. Ask your employees to read the policy, to sign and date the attached form and then return it to the security manager.

Because only 6.2 per cent of all users voluntarily return the signed policy within 90 days, you need to set up a little collection operation. Knock on doors with additional copies of your policy ("I lost it"), leave voice mail ("I'm on vacation this year"), wander through the mail room ("It's in the mail"), barter ("I'll sign your dumb policy if you'll fill out your timesheet correctly") and be firm ("Mr. Smith doesn't need to fill it out; he's head of marketing").

After your tally shows that you've received signed statements from everyone, file the forms in personnel records or maintain them by division, cost centre or other grouping.

Even if you manage to collect these consent forms from all employees showing that they have read the policy, remember that your organisation hires temporaries and new employees from time to time and they need to be informed about security policy. Include a briefing and review of the information security policy as part of new employee orientation and ensure that it is provided to any temps as part of their orientation as well. And don't forget contractors, consultants, vendors, customers and anyone else who uses your network. If you don't have a signed consent form, you don't have much proof that they knew about the policy. Without such proof, prosecution (or even dismissal or reprimand) is more difficult.

After everyone has read and signed the policy, don't be afraid to enforce it. If your policy indicates punishments for policy violations, be sure you follow the guidelines. Let others know when a punishment has been administered. Most people quickly figure out what policies are not enforced in an organisation. If you doubt this principle, consider this: when was the last time you drove 70 mph on a motorway for an entire trip?

Is it futile?

Policy, procedures and training are not enough. Symantec once helped a small law firm write a policy for backing up files. It followed all the brilliant advice outlined here, trained the staff in how to backup and added automatic backup procedures to their menus. Semantec also insisted the company purchase enough backup media for the job. Everyone agreed to follow the policy. Two months later, Semantec received a call. "Could you come in and help us recover a file?" When asked about backups, the company responded: "Nope. Not yet." Symantec were unable to recover the file and it was lost.

Awareness is not enough. Policy frequently fails to do what it was intended to do. Is policy futile? We think not. In organisations with decent policy, things may still be disorganised and mistakes still happen. But in organisations lacking policy, chaos reigns.

Compiled by Rachel Hodgkins

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in September 1999

 

COMMENTS powered by Disqus  //  Commenting policy