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.
AudienceAfter 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.
ContentWhat 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 implementationHere 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 risksUsers
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
yearPolicy 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
onePolicy 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
usersPolicy 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 occurPolicy 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 twoSo 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 solvePolicy 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