An IT Security Policy is aimed at protecting the Confidentiality, Integrity and Availability of resources, data and programs. Essentially, it will:

• Define what you want to protect
• Analyse what it is you want to protect it from
• Explain how you intend to protect it

To be effective, it must be both holistic and dynamic. To be achievable, it must be realistic in its goals, and (where user conformity is required) expressed in a way that is simple and short enough to ensure it is read, understood and followed.

The overall security policy will address such areas as:

• physical security of your data and systems
• access control to your data and systems
• data integrity and availability
• contingency and recovery plans (backups!!!)
• etcetera …

Anti-virus issues are simply one element of such a policy - viruses are one of the risks this policy must protect against.

The information that follows addresses this anti-virus component. To provide context, it includes considerations that would properly be covered at a higher level of an overall policy. The information presented is necessarily generic, and is not intended to be exhaustive - the content of any security policy ultimately rests with its author. However, this paper does provide a starting point for writing such a policy.

The paper is broken into two sections:

A risk analysis outlines all the threats to the viability of the business. It examines the likelihood of each threat occurring and the impact of that occurrence. This allows us to make informed decisions when assigning resources to manage our risk. We manage risk by controlling the vulnerabilities that expose us to it (if the threat is highly likely to eventuate), or planning how to recover from it (if the threat is unlikely, but must be guarded against). At its simplest, we might define nine broad levels of risk, each with an associated response, as follows:

Figure 1: Risk/Response Table

Obviously, response will vary according to company and resources. Some companies may aim to prevent the occurrence of any threat, regardless of its impact; others may choose to accept even high-impact threats. Similarly, different areas of the same company may define higher impacts or risks for the same threat. Finally, you may want to extend the granularity of the risk model, to define additional levels of both risk and impact, to allow a finer tuning of the assessment and responses.

The risk analysis requires consideration of the following:

• Operating Environment
• Business Systems
• Vulnerabilities
• Impact Assessment

Each of these sections is covered in detail below.

Here we define the environment within which the business operates. This allows us to assess sources of vulnerability both within and to that environment. For the purposes of this paper, our list will be limited to the computing environment, as this is where we are vulnerable to viruses. The assessment will cover both the physical elements and the "control" issues of this environment. The following lists suggest areas to be considered :

Physical Elements

• Platforms (Intel, DEC, Macintosh, etcetera)
• Operating Systems (DOS, Windows (all flavours), NetWare, UNIX, etcetera)
• Hardware (Dumb Terminals, Diskless Workstations, Desktop Systems, etcetera)
• Software (Off-the-shelf, Customised, Internally Developed, Non-business (eg games) etcetera)
• Communications (Network Types, Modems, other links)

"Control" Issues:

• Standardisation
• What is the level of server standardisation?
• What is the level of desktop standardisation?
• Users
• What is the level of user competence in terms of security issues?
• What controls are in place to ensure and monitor staff conformity to security policy?
• Externals
• Define our reliance on contractors, solution providers etc (for hardware and software)
• Define our reliance on external data and service providers (eg ISPs, stock-market feeds etc)
• Define what other external services and data we accept (newsfeeds, general downloads etc)

Armed with a broad overview of our system, we now turn to the specific components of our business system that need to be protected. Viruses directly threaten a company’s data and computer based services, and indirectly their reputation. Our task is thus to list all data and computer based services provided by or necessary to the company’s existence. The list will include, but not be limited to, objects from the following areas:

Internal Records

• databases
• spreadsheets and other financials
• documentation
• product and services information
• employee information
• strategic plans (by category/department)
• any other sensitive and/or confidential information (by category)
• etcetera

Electronically Provided or Supported Services

• Electronic order acceptance and Customer subscription services
• Information services
• etcetera

External "Product"

• "Data feeds" from external sources
• Access to external services necessary to run the business
• etcetera

In this section we examine the specific vulnerabilities inherent in how we do business. The analysis is broken into a number of parts, each of which follows on from those preceding it.

A threat is a general danger to the viability of our business. As we are confining our discussion to threats associated with viruses, which primarily target our systems and data, our threats may be limited to the following:

• Threats to data
• Threats to systems (software, comms, services)
• Threats to reputation
• Threats to finances
• Other …

In the wider scheme of things, this is where we would list all of the ways the above areas are threatened. Thus, while our focus is on the threat to our data from viral incidents, normally we would also identify our data being vulnerable to damage by anything from a major disaster, such as a fire or flood, through more common occurrences, like a hard drive failure, faulty cable, power interruption and simple user error.

This is also the place to identify how a vulnerability threatens us - i.e. its vector of attack. It is not enough to identify the susceptibility of our systems to a virus attack as a vulnerability - we also have to understand how viruses gain access to our systems, so that we can take measures to keep them out.

Our pre-work in defining the operating environment helps us here - it limits our list of vulnerabilities to those that target that environment.

An example list of the virus and associated vulnerabilities of a Wintel environment is shown in figure 2. Note that if it excludes, for instance, UNIX attacks such as worms etc. Similarly, a business that doesn’t use Microsoft Office would currently exclude macro viruses.

Here we define how exposed the business is to each of the threats identified. This is driven by an examination of the operating environment and the vectors of attack that threaten it, and is highly business specific. A sample (and cut-down) analysis is given below:

Having defined the areas that are threatened, and our exposure to viruses as a vulnerability that would realise those threats, we can combine the two to list the potential consequences of a virus infection.

Clearly, at this level the analysis will be highly dependent on the individual business. The above are simply some of the areas that need to be considered.

This is the final piece of the risk assessment. Having identified what our business areas are, and the threats to those areas, we now need to determine what impact it will have on our business if one of these areas is compromised.

Here impact is assessed in terms of the categories of "damage" that could be done to each data set and service identified. Some of the possible "damage" categories are listed across the top of Figure 5. The actual impact assessments are purely notional - they will vary by company.

A true risk analysis would also include some indication of the size and type of investment an object represents, and its "replaceability" should it be lost, along with the general impact assessment. The depth of analysis required for this section will be governed by the complexity and needs of the business. Where different business units come to different impact assessments on the same object, always record the highest impact.

Having identified the components of, and threats to, our system, our next step is to create the policies that will protect our business.

For the purposes of this discussion the "padding" that should go with this policy (Introduction, Statement of Purpose, Background, Context Statement, Definitions, Governing Policies, etc) are assumed. The focus of this section of the paper will be exclusively on developing the anti-viral component of a Security Policy.

Our goal will be governed by the potential business impact of each virus risk identified, and the cost of managing that risk. Some companies may not be able to risk any possibility of a virus infection, and will set extremely high anti-virus security goals; for others it may be cost-effective to deal with the infections as they arise. The key issue here is to balance the effort and cost required to keep viruses out against the business exposure to viruses and the potential impact of a virus incident identified in the risk assessment.

Our goal will fall somewhere in the following broad spectrum:

• No virus incidents
• All viruses detected and contained at the perimeter of the business environment
• All viruses detected and contained as soon as they enter the business environment
• X% of viruses detected and contained as soon as they enter the business environment; virus incidents caused by the (100-X)% that escape initial detection handled according to our security policy
• Viruses incidents are an accepted part of the business environment

Generally, ultimate responsibility for the anti-virus policy and implementation lies with whoever writes the security policy document, though this is not always the case. It is important that this person/department is identified and given sufficient authority to achieve the goals of the policy.

At its most basic, the following duties and responsibilities will exist within most companies (though the actual hierarchy may differ significantly):

In the above model, the IS manager and their team select, implement and support the suite of security packages they have chosen to drive this policy, ensuring both the policy itself and the packages chosen to implement it are kept up to date. The role of the help-desk is to ensure the policy is understood, followed and supported. This is a typical approach that places responsibility with the experts and frees the users to get on with their jobs.

(The specific responsibilities (expected actions and behaviour) of the users are discussed in section 5 of this paper)

The baseline defines our minimum security implementation.

For simple ease of management, it would be ideal if we could define and implement a single baseline for the entire company; in practice, the number and diversity of systems and business units may make this impossible.

The baseline will derive from the information discovered in the risk assessment, and may require changes to our operating environment. Figure 6 lists some of the areas that might be considered along with a selection of potential policy decisions, and some consideration of the gains and costs of implementing each. A more complete analysis would also list the gaps left open by the baseline.

Please note that Figure 6 is not intended to be an exhaustive listing of security alternatives, but simply a starting point for consideration of the security alternatives available.

It is also to be noted that both the baseline and additional security sections will give some indication of how often they should be reviewed and updated.

Additional security measures aim at controlling the "high-risk" areas of the business identified in the risk analysis. These may address applications that have been identified as open to particular attack, business-critical units, and responses to particular types of threat. For example, VetMail, listed below, is specifically targeted at closing exposure to viruses attached to e-mail messages.

Clearly the distinction between the security baseline and additional security measures will be highly company specific. Any of the alternatives listed in Figure 6 may be reserved as additional security measures, just as the additional controls listed below could be implemented as part of the security baseline.

Anti-virus security products provided by Cybec include:

• Vet for DOS, Windows 3x, Windows 95 and Windows NT workstation
  On demand and automatic virus checking and cleaning
• Vet for Windows NT Server
  On demand and automatic virus checking and cleaning; scheduled virus checking
• VetNet for NetWare 3 and NetWare 4
  On demand and automatic virus checking and cleaning; scheduled virus checking
• VetMail
  An e-mail filter program hosted on an NT server, that checks all mail and attachments directed through that box. (Creates a choke-point to ensure that mail and attachments entering and leaving the company are not infected)

Vet can be implemented across the organisation, or as a perimeter solution. The latter approach uses the concept of choke-points, where all threatening items are checked before being allowed into the system. The choke-point approach may be implemented as an additional measure for high risk areas of the business, or as a security baseline.

Potential choke-points include:

• Connections to the outside world (force all such connections through controlled, shared modems, rather than allowing individual users their own modems)
• Controlling all software that comes into the company (by defining and enforcing a standardised desktop for instance)

Some specific risks that will be managed by our additional security measures include:

• Laptops/mobile users (unless tightly controlled exist outside the security perimeter)
• Contractors/Service personnel/Suppliers etc
• Downloaded software
• Disks, programs, documents brought from outside the office
• Unauthorised software
• Deliberate attack

While a security solution may be largely imposed through a policy driven selection and implementation of hardware and software, it will always include behavioural elements as well. The Procedures Document outlines the expected behaviour of the users within the system. As such it must be concise, simple to read, and easy to understand. Ideally it will be backed up with a comprehensive awareness campaign that delivers enough knowledge on the problem and the company’s policy and solutions to it, to ensure the users are correctly playing their role in meeting this security threat. Clearly, there may be a number of sections to the procedure document, each targeted at the next level of responsibility within the company.

A basic procedures document will outline what users can (and cannot) do on the system, as well as the procedure to follow if they know or suspect they have a virus outbreak. It will consist of at least some of the following elements:

• Outline of prohibited actions (eg No games, disks, modems; no altering desktop etc)
• Outline of required actions (eg Scan all disks, downloads etc)
• Outline of reporting procedures (When and what to report, and to whom)
• Outline of incident response and escalation strategies (What the help desk is to do if an incident, or suspected incident is reported)
• Review strategies (What will be done if the system fails)

Our ultimate aim here is to turn our users into "responsible hypochondriacs". Our reporting and escalation strategy will determine how this works, but essentially what we want is that users report suspicious behavior to the appropriate source. This has the double advantage of raising the probability that virus incidents will be discovered early while preventing a flood of hoax messages, by ensuring they are forwarded to the appropriate point and nowhere else.

The awareness plan will be a plan of action to raise users understanding of the risks the business is exposed to and how their actions can affect that exposure. It may include:

• Basic introduction to how viruses work, or at least to the actions that can introduce a virus
• Introduction to the extended virus problem, discussing issues such as hoaxes and trojan horse attacks
• Explanation of the security strategy adopted by the company:
• the tools available to them
• the procedures they must follow
• Outline the disciplinary or corrective measures that will be taken should the above procedures be violated

Any education program risks being simply an information dump unless there is appropriate follow-up and reinforcement of the information learned. Suggested techniques include:

• Action Cards to be kept on users desks, which list the minimum actions a user should take if they suspect they have a virus, plus the policy points that define what they should and should not do to prevent a virus attack
• Regular email or memos to users advising them when their anti-virus software has been updated, and recapitulating a particular security consideration, gradually cycling through the above list of topics
• Analyses of any security breaches that occur, and how they can be prevented
• Reports of the success of the security policy - for example, a regular report of the number of viruses detected before they could make it in to the system
• Immediate notification of changes to the security situation (such as a new type of virus, or a new anti-virus tool). Preferably a dedicated training session to address the new threat
• Pre-emptive notification of hoax messages
• Refresher training programs
• Firedrills

Cybec and the author of this paper separately and jointly make no representations about the suitability of the information contained in this White Paper for any purpose. The document is provided "as is"

without warranty of any kind. No responsibility or liability will be accepted by the author or Cybec for any damages caused by direct or indirect use of the information or functionality described in this paper.

Permission to use this document is granted, provided that:

1. this copyright notice appears in all copies and that both the copyright notice and this permission notice appear
1. use of this document is for informational and non-commercial or personal use only and will not be copied or posted on any network computer or broadcast in any media
1. no modifications are made to this document

Use for any other purpose is expressly prohibited by law, and may result in severe civil and criminal penalties. Violators will be prosecuted to the maximum extent possible.

The contents of this paper remain copyright Cybec. Suggestions and comments are welcome, and should be addressed to the author:

email NEngelman@vet.com.au

mail N Engelman

1601 Malvern Road

Glen Iris, Vic, Australia

3146