431 lines
21 KiB
Plaintext
431 lines
21 KiB
Plaintext
|
ZDDDDDDDDDDDDDDDDDD? IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM; ZDDDDDDDDDDDDDDDDDD?
|
||
|
3 Founded By: 3 : Network Information Access : 3 Mother Earth BBS 3
|
||
|
3 Guardian Of Time 3D: 17APR90 :D3 NUP:> DECnet 3
|
||
|
3 Judge Dredd 3 : Judge Dredd : 3Text File Archives3
|
||
|
@DDDDDDDDBDDDDDDDDDY : File 24 : @DDDDDDDDDBDDDDDDDDY
|
||
|
3 HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM< 3
|
||
|
3 IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM; 3
|
||
|
@DDDDDDDDDDD6 Computer Viruses & Threats II GDDDDDDDDDDDY
|
||
|
HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM<
|
||
|
|
||
|
$_Virus Prevention in General
|
||
|
|
||
|
|
||
|
To provide general protection from attacks by computer viruses,
|
||
|
unauthorized users, and related threats, users and managers need
|
||
|
to eliminate or reduce vulnerabilities. A general summary of the
|
||
|
vulnerabilities that computer viruses and related threats are
|
||
|
most likely to exploit is as follows:
|
||
|
|
||
|
- lack of user awareness - users copy and share infected
|
||
|
software, fail to detect signs of virus activity, do not
|
||
|
understand proper security techniques
|
||
|
|
||
|
- absence of or inadequate security controls - personal
|
||
|
computers generally lack software and hardware security
|
||
|
mechanisms that help to prevent and detect unauthorized
|
||
|
use, existing controls on multi-user systems can
|
||
|
sometimes be surmounted by knowledgeable users
|
||
|
|
||
|
- ineffective use of existing security controls - using
|
||
|
easily guessed passwords, failing to use access controls,
|
||
|
granting users more access to resources than necessary
|
||
|
|
||
|
- bugs and loopholes in system software - enabling
|
||
|
knowledgeable users to break into systems or exceed their
|
||
|
authorized privileges
|
||
|
|
||
|
- unauthorized use - unauthorized users can break in to
|
||
|
systems, authorized users can exceed levels of privilege
|
||
|
and misuse systems
|
||
|
|
||
|
- susceptibility of networks to misuse - networks can
|
||
|
provide anonymous access to systems, many are in general
|
||
|
only as secure as the systems which use them
|
||
|
|
||
|
As can be seen from this summary, virus prevention requires that
|
||
|
many diverse vulnerabilities be addressed. Some of the
|
||
|
vulnerabilities can be improved upon significantly, such as
|
||
|
security controls that can be added or improved, while others are
|
||
|
somewhat inherent in computing, such as the risk that users will
|
||
|
not use security controls or follow policies, or the risk of
|
||
|
unauthorized use of computers and networks. Thus, it may not be
|
||
|
possible to completely protect systems from all virus-like
|
||
|
attacks. However, to attain a realistic degree of protection,
|
||
|
all areas of vulnerability must be addressed; improving upon some
|
||
|
areas at the expense of others will still leave significant holes
|
||
|
in security.
|
||
|
|
||
|
|
||
|
To adequately address all areas of vulnerability, the active
|
||
|
involvement of individual users, the management structure, and
|
||
|
the organization in a virus prevention program is essential.
|
||
|
Such a program, whether formal or informal, depends on the mutual
|
||
|
cooperation of the three groups to identify vulnerabilities, to
|
||
|
take steps to correct them, and to monitor the results.
|
||
|
|
||
|
A virus prevention program must be initially based upon effective
|
||
|
system computer administration that restricts access to
|
||
|
authorized users, ensures that hardware and software are
|
||
|
regularly monitored and maintained, makes backups regularly, and
|
||
|
maintains contingency procedures for potential problems. Sites
|
||
|
that do not maintain a basic computer administration program need
|
||
|
to put one into place, regardless of their size or the types of
|
||
|
computers used. Many system vendors supply system administration
|
||
|
manuals that describe the aspects of a basic program.
|
||
|
|
||
|
Once a basic administration program is in place, management and
|
||
|
users need to incorporate virus prevention measures that will
|
||
|
help to deter attacks by viruses and related threats, detect when
|
||
|
they occur, contain the attacks to limit damage, and recover in a
|
||
|
reasonable amount of time without loss of data. To accomplish
|
||
|
these aims, attention needs to be focused on the following areas:
|
||
|
|
||
|
- educating users about malicious software in general, the
|
||
|
risks that it poses, how to use control measures,
|
||
|
policies, and procedures to protect themselves and the
|
||
|
organization
|
||
|
|
||
|
- software management policies and procedures that address
|
||
|
public-domain software, and the use and maintenance of
|
||
|
software in general
|
||
|
|
||
|
- use of technical controls that help to prevent and deter
|
||
|
attacks by malicious software and unauthorized users
|
||
|
|
||
|
- monitoring of user and software activity to detect signs
|
||
|
of attacks, to detect policy violations, and to monitor
|
||
|
the overall effectiveness of policies, procedures, and
|
||
|
controls
|
||
|
|
||
|
- contingency policies and procedures for containing and
|
||
|
recovering from attacks
|
||
|
|
||
|
General guidance in each of these areas is explained in the
|
||
|
following sections.
|
||
|
|
||
|
|
||
|
$_Education
|
||
|
|
||
|
|
||
|
Education is one of the primary methods by which systems and
|
||
|
organizations can achieve greater protection from incidents of
|
||
|
malicious software and unauthorized use. In situations where
|
||
|
technical controls do not provide complete protection (i.e., most
|
||
|
computers), it is ultimately people and their willingness to
|
||
|
adhere to security policies that will determine whether systems
|
||
|
and organizations are protected. By educating users about the
|
||
|
general nature of computer viruses and related threats, an
|
||
|
organization can improve its ability to deter, detect, contain
|
||
|
|
||
|
Users should be educated about the following:
|
||
|
|
||
|
- how malicious software operates, methods by which it is
|
||
|
planted and spread, the vulnerabilities exploited by
|
||
|
malicious software and unauthorized users
|
||
|
|
||
|
- general security policies and procedures and how to use
|
||
|
them
|
||
|
|
||
|
- the policies to follow regarding the backup, storage, and
|
||
|
use of software, especially public-domain software and
|
||
|
shareware
|
||
|
|
||
|
- how to use the technical controls they have at their
|
||
|
disposal to protect themselves
|
||
|
|
||
|
- how to monitor their systems and software to detect signs
|
||
|
of abnormal activity, what to do or whom to contact for
|
||
|
more information
|
||
|
|
||
|
- contingency procedures for containing and recovering from
|
||
|
potential incidents
|
||
|
|
||
|
User education, while perhaps expensive in terms of time and
|
||
|
resources required, is ultimately a cost-effective measure for
|
||
|
protecting against incidents of malicious software and
|
||
|
unauthorized use. Users who are better acquainted with the
|
||
|
destructive potential of malicious software and the methods by
|
||
|
which it can attack systems may in turn be prompted to take
|
||
|
measures to protect themselves. The purpose of security policies
|
||
|
and procedures will be more clear, thus users may be more willing
|
||
|
to actively use them. By educating users how to detect abnormal
|
||
|
system activity and the resultant steps to follow for containing
|
||
|
and recovering from potential incidents, organizations will save
|
||
|
money and time if and when actual incidents occur.
|
||
|
|
||
|
$_Software Management
|
||
|
|
||
|
|
||
|
As shown by examples in File 1, one of the prime methods by
|
||
|
which malicious software is initially copied onto systems is by
|
||
|
unsuspecting users. When users download programs from sources
|
||
|
such as software bulletin boards, or public directories on
|
||
|
systems or network servers, or in general use and share software
|
||
|
that has not been obtained from a reputable source, users are in
|
||
|
danger of spreading malicious software. To prevent users from
|
||
|
potentially spreading malicious software, managers need to
|
||
|
|
||
|
- ensure that users understand the nature of malicious
|
||
|
software, how it is generally spread, and the technical
|
||
|
controls to use to protect themselves
|
||
|
|
||
|
- develop policies for the downloading and use of public-
|
||
|
domain and shareware software
|
||
|
|
||
|
- create some mechanism for validating such software prior
|
||
|
to allowing users to copy and use it
|
||
|
|
||
|
- minimize the exchange of executable software within an
|
||
|
organization as much as possible
|
||
|
|
||
|
- do not create software repositories on LAN servers or in
|
||
|
multi-user system directories unless technical controls
|
||
|
exist to prevent users from freely uploading or
|
||
|
downloading the software
|
||
|
|
||
|
The role of education is important, as users who do not
|
||
|
understand the risks yet who are asked to follow necessarily
|
||
|
restrictive policies may share and copy software anyway. Where
|
||
|
technical controls cannot prevent placing new software onto a
|
||
|
system, users are then primarily responsible for the success or
|
||
|
failure of whatever policies are developed.
|
||
|
|
||
|
A policy that prohibits any copying or use of public-domain
|
||
|
software may be overly restrictive, as some public domain
|
||
|
programs have proved to be useful. A less restrictive policy
|
||
|
would allow some copying, however a user might first require
|
||
|
permission from the appropriate manager. A special system should
|
||
|
be used from which to perform the copy and then to test the
|
||
|
software. This type of system, called an isolated system, should
|
||
|
be configured so that there is no risk of spreading a potentially
|
||
|
malicious program to other areas of an organization. The system
|
||
|
should not be used by other users, should not connect to
|
||
|
networks, and should not contain any valuable data. An isolated
|
||
|
system should also be used to test internally developed software
|
||
|
and updates to vendor software.
|
||
|
|
||
|
Other policies for managing vendor software should be developed.
|
||
|
These policies should control how and where software is
|
||
|
purchased, and should govern where the software is installed and
|
||
|
how it is to be used. The following policies and procedures are
|
||
|
suggested:
|
||
|
|
||
|
- purchase vendor software only from reputable sources
|
||
|
|
||
|
- maintain the software properly and update it as necessary
|
||
|
|
||
|
- don't use pirated software, as it may have been modified
|
||
|
|
||
|
- keep records of where software is installed readily
|
||
|
available for contingency purposes
|
||
|
|
||
|
- ensure that vendors can be contacted quickly if problems
|
||
|
occur
|
||
|
|
||
|
- store the original disks or tapes from the vendor in a
|
||
|
secure location
|
||
|
|
||
|
|
||
|
$_Technical Controls
|
||
|
|
||
|
Technical controls are the mechanisms used to protect the
|
||
|
security and integrity of systems and associated data. The use
|
||
|
of technical controls can help to prevent occurrences of viruses
|
||
|
and related threats by deterring them or making it more difficult
|
||
|
for them to gain access to systems and data. Examples of
|
||
|
technical controls include user authentication mechanisms such as
|
||
|
passwords, mechanisms which provide selective levels of access to
|
||
|
files and directories (read-only, no access, access to certain
|
||
|
users, etc.), and write-protection mechanisms on tapes and
|
||
|
diskettes.
|
||
|
|
||
|
|
||
|
The different types of technical controls and the degree to which
|
||
|
they can provide protection and deterrence varies from system to
|
||
|
system, thus the use of specific types of controls is discussed
|
||
|
in the following files. However, the following general points are
|
||
|
important to note:
|
||
|
|
||
|
- technical controls should be used as available to
|
||
|
restrict system access to authorized users only
|
||
|
|
||
|
- in the multi-user environment, technical controls should
|
||
|
be used to limit users' privileges to the minimum
|
||
|
practical level; they should work automatically and need
|
||
|
not be initiated by users
|
||
|
|
||
|
- users and system managers must be educated as to how and
|
||
|
when to use technical controls
|
||
|
|
||
|
- where technical controls are weak or non-existent (i.e.,
|
||
|
personal computers), they should be supplemented with
|
||
|
alternative physical controls or add-on control
|
||
|
mechanisms
|
||
|
|
||
|
Managers need to determine which technical controls are available
|
||
|
on their systems, and then the degree to which they should be
|
||
|
used and whether additional add-on controls are necessary. One
|
||
|
way to answer these questions is to first categorize the
|
||
|
different classes of data being processed by a system or systems,
|
||
|
and then to rank the categories according to criteria such as
|
||
|
sensitivity to the organization and vulnerability of the system
|
||
|
to attack. The rankings should then help determine the degree to
|
||
|
which the controls should be applied and whether additional
|
||
|
controls are necessary. Ideally, those systems with the most
|
||
|
effective controls should be used to process the most sensitive
|
||
|
data, and vice-versa. As an example, a personal computer which
|
||
|
processes sensitive employee information should require add-on
|
||
|
user authentication mechanisms, whereas a personal computer used
|
||
|
for general word processing may not need additional controls.
|
||
|
|
||
|
|
||
|
It is important to note that technical controls do not generally
|
||
|
provide complete protection against viruses and related threats.
|
||
|
They may be cracked by determined users who are knowledgeable of
|
||
|
hidden bugs and weaknesses, and they may be surmounted through
|
||
|
the use of Trojan horse programs, as shown by examples in File
|
||
|
1. An inherent weakness in technical controls is that, while
|
||
|
deterring users and software from objects to which they do not
|
||
|
have access, they may be totally ineffective against attacks
|
||
|
which target objects that are accessible. For example, technical
|
||
|
controls may not prevent an authorized user from destroying files
|
||
|
to which the user has authorized access. Most importantly, when
|
||
|
technical controls are not used properly, they may increase a
|
||
|
system's degree of vulnerability. It is generally agreed that
|
||
|
fully effective technical controls will not be widely available
|
||
|
for some time. Because of the immediate nature of the computer
|
||
|
virus threat, technical controls must be supplemented by less
|
||
|
technically-oriented control measures such as described in this
|
||
|
chapter.
|
||
|
|
||
|
$_General Monitoring
|
||
|
|
||
|
An important aspect of computer viruses and related threats is
|
||
|
that they potentially can cause extensive damage within a very
|
||
|
small amount of time, such as minutes or seconds. Through proper
|
||
|
monitoring of software, system activity, and in some cases user
|
||
|
activity, managers can increase their chances that they will
|
||
|
detect early signs of malicious software and unauthorized
|
||
|
activity. Once the presence is noted or suspected, managers can
|
||
|
then use contingency procedures to contain the activity and
|
||
|
recover from whatever damage has been caused. An additional
|
||
|
benefit of general monitoring is that over time, it can aid in
|
||
|
determining the necessary level or degree of security by
|
||
|
indicating whether security policies, procedures, and controls
|
||
|
are working as planned.
|
||
|
|
||
|
Monitoring is a combination of continual system and system
|
||
|
management activity. Its effectiveness depends on cooperation
|
||
|
between management and users. The following items are necessary
|
||
|
for effective monitoring:
|
||
|
|
||
|
- user education - users must know, specific to their
|
||
|
computing environment, what constitutes normal and
|
||
|
abnormal system activity and whom to contact for further
|
||
|
information - this is especially important for users of
|
||
|
personal computers, which generally lack automated
|
||
|
methods for monitoring
|
||
|
|
||
|
- automated system monitoring tools - generally on multi-
|
||
|
user systems, to automate logging or accounting of user
|
||
|
and software accesses to accounts, files, and other
|
||
|
system objects - can sometimes be tuned to record only
|
||
|
certain types of accesses such as "illegal" accesses
|
||
|
|
||
|
- anti-viral software - generally on personal computers,
|
||
|
these tools alert users of certain types of system access
|
||
|
that are indicative of "typical" malicious software
|
||
|
|
||
|
- system-sweep programs - programs to automatically check
|
||
|
files for changes in size, date, or content
|
||
|
|
||
|
- network monitoring tools - as with system monitoring
|
||
|
tools, to record network accesses or attempts to access
|
||
|
|
||
|
The statistics gained from monitoring activities should be used
|
||
|
as input for periodic reviews of security programs. The reviews
|
||
|
should evaluate the effectiveness of general system management,
|
||
|
and associated security policies, procedures, and controls. The
|
||
|
statistics will indicate the need for changes and will help to
|
||
|
fine tune the program so that security is distributed to where it
|
||
|
is most necessary. The reviews should also incorporate users'
|
||
|
suggestions, and to ensure that the program is not overly
|
||
|
restrictive, their criticisms.
|
||
|
|
||
|
$_Contingency Planning
|
||
|
|
||
|
|
||
|
The purpose of contingency planning with regard to computer
|
||
|
viruses and related threats is to be able to contain and recover
|
||
|
completely from actual attacks. In many ways, effective system
|
||
|
management that includes user education, use of technical
|
||
|
controls, software management, and monitoring activities, is a
|
||
|
form of contingency planning, generally because a well-run,
|
||
|
organized system or facility is better able to withstand the
|
||
|
disruption that could result from a computer virus attack. In
|
||
|
addition to effective system management activities, managers need
|
||
|
to consider other contingency procedures that specifically take
|
||
|
into account the nature of computer viruses and related threats.
|
||
|
|
||
|
Possibly the most important contingency planning activity
|
||
|
involves the use of backups. The ability to recover from a virus
|
||
|
attack depends upon maintaining regular, frequent backups of all
|
||
|
system data. Each backup should be checked to ensure that the
|
||
|
backup media has not been corrupted. Backup media could easily
|
||
|
be corrupted because of defects, because the backup procedure was
|
||
|
incorrect, or perhaps because the backup software itself has been
|
||
|
attacked and modified to corrupt backups as they are made.
|
||
|
|
||
|
Contingency procedures for restoring from backups after a virus
|
||
|
attack are equally important. Backups may contain copies of
|
||
|
malicious software that have been hiding in the system.
|
||
|
Restoring the malicious software to a system that has been
|
||
|
attacked could cause a recurrence of the problem. To avoid this
|
||
|
possibility, software should be restored only from its original
|
||
|
media: the tapes or diskettes from the vendor. In some cases,
|
||
|
this may involve reconfiguring the software, therefore managers
|
||
|
must maintain copies of configuration information for system and
|
||
|
application software. Because data is not directly executable,
|
||
|
it can be restored from routine backups. However, data that has
|
||
|
been damaged may need to be restored manually or from older
|
||
|
backups. Command files such as batch procedures and files
|
||
|
executed when systems boot or when user log on should be
|
||
|
inspected to ensure that they have not been damaged or modified.
|
||
|
Thus, managers will need to retain successive versions of
|
||
|
backups, and search through them when restoring damaged data and
|
||
|
command files.
|
||
|
|
||
|
Other contingency procedures for containing virus attacks need to
|
||
|
be developed. The following are suggested; they are discussed in
|
||
|
more detail in following files:
|
||
|
|
||
|
|
||
|
- ensure that accurate records are kept of each system's
|
||
|
configuration, including the system's location, the
|
||
|
software it runs, the system's network and modem
|
||
|
connections, and the name of the system's manager or
|
||
|
responsible individual
|
||
|
|
||
|
- create a group of skilled users to deal with virus
|
||
|
incidents and ensure that users can quickly contact this
|
||
|
group if they suspect signs of viral activity
|
||
|
|
||
|
- maintain a security distribution list at each site with
|
||
|
appropriate telephone numbers of managers to contact when
|
||
|
problems occur
|
||
|
|
||
|
- isolate critical systems from networks and other sources
|
||
|
of infection
|
||
|
|
||
|
- place outside network connections on systems with the
|
||
|
best protections, use central gateways to facilitate
|
||
|
rapid disconnects
|
||
|
|
||
|
-JUDGE DREDD/NIA
|
||
|
|
||
|
[OTHER WORLD BBS]
|
||
|
|
||
|
|
||
|
|