its own users if their data or systems become compromised
during the pursuit.
2.6 Interpreting the Policy
It is important to define who will interpret the policy. This could
be an individual or a committee. No matter how well written, the
policy will require interpretation from time to time and this body
would serve to review, interpret, and revise the policy as needed.
2.7 Publicizing the Policy
Once the site security policy has been written and established, a
vigorous process should be engaged to ensure that the policy
statement is widely and thoroughly disseminated and discussed. A
mailing of the policy should not be considered sufficient. A period
for comments should be allowed before the policy becomes effective to
ensure that all affected users have a chance to state their reactions
and discuss any unforeseen ramifications. Ideally, the policy should
strike a balance between protection and productivity.
Meetings should be held to elicit these comments, and also to ensure
that the policy is correctly understood. (Policy promulgators are
not necessarily noted for their skill with the language.) These
meetings should involve higher management as well as line employees.
Security is a collective effort.
In addition to the initial efforts to publicize the policy, it is
essential for the site to maintain a continual awareness of its
computer security policy. Current users may need periodic reminders
New users should have the policy included as part of their site
introduction packet. As a condition for using the site facilities,
it may be advisable to have them sign a statement that they have read
and understood the policy. Should any of these users require legal
action for serious policy violations, this signed statement might
prove to be a valuable aid.
3. Establishing Procedures to Prevent Security Problems
The security policy defines what needs to be protected. This section
discusses security procedures which specify what steps will be used
to carry out the security policy.
3.1 Security Policy Defines What Needs to be Protected
The security policy defines the WHAT's: what needs to be protected,
what is most important, what the priorities are, and what the general
approach to dealing with security problems should be.
The security policy by itself doesn't say HOW things are protected.
That is the role of security procedures, which this section
discusses. The security policy should be a high level document,
giving general strategy. The security procedures need to set out, in
detail, the precise steps your site will take to protect itself.
The security policy should include a general risk assessment of the
types of threats a site is mostly likely to face and the consequences
of those threats (see section 2.2). Part of doing a risk assessment
will include creating a general list of assets that should be
protected (section 2.2.2). This information is critical in devising
cost-effective procedures.
It is often tempting to start creating security procedures by
deciding on different mechanisms first: "our site should have logging
on all hosts, call-back modems, and smart cards for all users." This
approach could lead to some areas that have too much protection for
the risk they face, and other areas that aren't protected enough.
Starting with the security policy and the risks it outlines should
ensure that the procedures provide the right level of protect for all
assets.
3.2 Identifing Possible Problems
To determine risk, vulnerabilities must be identified. Part of the
purpose of the policy is to aid in shoring up the vulnerabilities and
thus to decrease the risk in as many areas as possible. Several of
the more popular problem areas are presented in sections below. This
list is by no means complete. In addition, each site is likely to
have a few unique vulnerabilities.
3.2.1 Access Points
Access points are typically used for entry by unauthorized users.
Having many access points increases the risk of access to an
organization's computer and network facilities.
Network links to networks outside the organization allow access
into the organization for all others connected to that external
network. A network link typically provides access to a large
number of network services, and each service has a potential to be
compromised.
Dialup lines, depending on their configuration, may provide access
merely to a login port of a single system. If connected to a
terminal server, the dialup line may give access to the entire
network.
Terminal servers themselves can be a source of problem. Many
terminal servers do not require any kind of authentication.
Intruders often use terminal servers to disguise their actions,
dialing in on a local phone and then using the terminal server to
go out to the local network. Some terminal servers are configured
so that intruders can TELNET [19] in from outside the network, and
then TELNET back out again, again serving to make it difficult to
trace them.
3.2.2 Misconfigured Systems
Misconfigured systems form a large percentage of security holes.
Today's operating systems and their associated software have
become so complex that understanding how the system works has
become a full-time job. Often, systems managers will be non-
specialists chosen from the current organization's staff.
Vendors are also partly responsible for misconfigured systems. To
make the system installation process easier, vendors occasionally
choose initial configurations that are not secure in all
environments.
3.2.3 Software Bugs
Software will never be bug free. Publicly known security bugs are
common methods of unauthorized entry. Part of the solution to
this problem is to be aware of the security problems and to update
the software when problems are detected. When bugs are found,
they should be reported to the vendor so that a solution to the
problem can be implemented and distributed.
3.2.4 "Insider" Threats
An insider to the organization may be a considerable threat to the
security of the computer systems. Insiders often have direct
access to the computer and network hardware components. The
ability to access the components of a system makes most systems
easier to compromise. Most desktop workstations can be easily
manipulated so that they grant privileged access. Access to a
local area network provides the ability to view possibly sensitive
data traversing the network.
3.3 Choose Controls to Protect Assets in a Cost-Effective Way
After establishing what is to be protected, and assessing the risks
these assets face, it is necessary to decide how to implement the
controls which protect these assets. The controls and protection
mechanisms should be selected in a way so as to adequately counter
the threats found during risk assessment, and to implement those
controls in a cost effective manner. It makes little sense to spend
an exorbitant sum of money and overly constrict the user base if the
risk of exposure is very small.
3.3.1 Choose the Right Set of Controls
The controls that are selected represent the physical embodiment
of your security policy. They are the first and primary line of
defense in the protection of your assets. It is therefore most
important to ensure that the controls that you select are the
right set of controls. If the major threat to your system is
outside penetrators, it probably doesn't make much sense to use
biometric devices to authenticate your regular system users. On
the other hand, if the major threat is unauthorized use of
computing resources by regular system users, you'll probably want
to establish very rigorous automated accounting procedures.
3.3.2 Use Common Sense
Common sense is the most appropriate tool that can be used to
establish your security policy. Elaborate security schemes and
mechanisms are impressive, and they do have their place, yet there
is little point in investing money and time on an elaborate
implementation scheme if the simple controls are forgotten. For
example, no matter how elaborate a system you put into place on
top of existing security controls, a single user with a poor
password can still leave your system open to attack.
3.4 Use Multiple Strategies to Protect Assets
Another method of protecting assets is to use multiple strategies.
In this way, if one strategy fails or is circumvented, another
strategy comes into play to continue protecting the asset. By using
several simpler strategies, a system can often be made more secure
than if one very sophisticated method were used in its place. For
example, dial-back modems can be used in conjunction with traditional
logon mechanisms. Many similar approaches could be devised that
provide several levels of protection for assets. However, it's very
easy to go overboard with extra mechanisms. One must keep in mind
exactly what it is that needs to be protected.
3.5 Physical Security
It is a given in computer security if the system itself is not
physically secure, nothing else about the system can be considered
secure. With physical access to a machine, an intruder can halt the
machine, bring it back up in privileged mode, replace or alter the
disk, plant Trojan horse programs (see section 2.13.9.2), or take any
number of other undesirable (and hard to prevent) actions.
Critical communications links, important servers, and other key
machines should be located in physically secure areas. Some security
systems (such as Kerberos) require that the machine be physically
secure.
If you cannot physically secure machines, care should be taken about
trusting those machines. Sites should consider limiting access from
non-secure machines to more secure machines. In particular, allowing
trusted access (e.g., the BSD Unix remote commands such as rsh) from
these kinds of hosts is particularly risky.
For machines that seem or are intended to be physically secure, care
should be taken about who has access to the machines. Remember that
custodial and maintenance staff often have keys to rooms.
3.6 Procedures to Recognize Unauthorized Activity
Several simple procedures can be used to detect most unauthorized
uses of a computer system. These procedures use tools provided with
the operating system by the vendor, or tools publicly available from
other sources.
3.6.1 Monitoring System Use
System monitoring can be done either by a system administrator, or
by software written for the purpose. Monitoring a system involves
looking at several parts of the system and searching for anything
unusual. Some of the easier ways to do this are described in this
section.
The most important thing about monitoring system use is that it be
done on a regular basis. Picking one day out of the month to
monitor the system is pointless, since a security breach can be
isolated to a matter of hours. Only by maintaining a constant
vigil can you expect to detect security violations in time to
react to them.
3.6.2 Tools for Monitoring the System
This section describes tools and methods for monitoring a system
against unauthorized access and use.
3.6.2.1 Logging
Most operating systems store numerous bits of information in
log files. Examination of these log files on a regular basis
is often the first line of defense in detecting unauthorized
use of the system.
- Compare lists of currently logged in users and past
login histories. Most users typically log in and out
at roughly the same time each day. An account logged
in outside the "normal" time for the account may be in
use by an intruder.
- Many systems maintain accounting records for billing
purposes. These records can also be used to determine
usage patterns for the system; unusual accounting records
may indicate unauthorized use of the system.
- System logging facilities, such as the UNIX "syslog"
utility, should be checked for unusual error messages
from system software. For example, a large number of
failed login attempts in a short period of time may
indicate someone trying to guess passwords.
- Operating system commands which list currently executing
processes can be used to detect users running programs
they are not authorized to use, as well as to detect
unauthorized programs which have been started by an
intruder.
3.6.2.2 Monitoring Software
Other monitoring tools can easily be constructed using standard
operating system software, by using several, often unrelated,
programs together. For example, checklists of file ownerships
and permission settings can be constructed (for example, with
"ls" and "find" on UNIX) and stored off-line. These lists can
then be reconstructed periodically and compared against the
master checklist (on UNIX, by using the "diff" utility).
Differences may indicate that unauthorized modifications have
been made to the system.
Still other tools are available from third-party vendors and
public software distribution sites. Section 3.9.9 lists
several sources from which you can learn what tools are
available and how to get them.
3.6.2.3 Other Tools
Other tools can also be used to monitor systems for security
violations, although this is not their primary purpose. For
example, network monitors can be used to detect and log
connections from unknown sites.
3.6.3 Vary the Monitoring Schedule
The task of system monitoring is not as daunting as it may seem.
System administrators can execute many of the commands used for
monitoring periodically throughout the day during idle moments
(e.g., while talking on the telephone), rather than spending fixed
periods of each day monitoring the system. By executing the
commands frequently, you will rapidly become used to seeing
"normal" output, and will easily spot things which are out of the
ordinary. In addition, by running various monitoring commands at
different times throughout the day, you make it hard for an
intruder to predict your actions. For example, if an intruder
knows that each day at 5:00 p.m. the system is checked to see that
everyone has logged off, he will simply wait until after the check
has completed before logging in. But the intruder cannot guess
when a system administrator might type a command to display all
logged-in users, and thus he runs a much greater risk of
detection.
Despite the advantages that regular system monitoring provides,
some intruders will be aware of the standard logging mechanisms in
use on systems they are attacking. They will actively pursue and
attempt to disable monitoring mechanisms. Regular monitoring
therefore is useful in detecting intruders, but does not provide
any guarantee that your system is secure, nor should monitoring be
considered an infallible method of detecting unauthorized use.
3.7 Define Actions to Take When Unauthorized Activity is Suspected
Sections 2.4 and 2.5 discussed the course of action a site should
take when it suspects its systems are being abused. The computer
security policy should state the general approach towards dealing
with these problems.
The procedures for dealing with these types of problems should be
written down. Who has authority to decide what actions will be
taken? Should law enforcement be involved? Should your
organization cooperate with other sites in trying to track down an
intruder? Answers to all the questions in section 2.4 should be
part of the incident handling procedures.
Whether you decide to lock out or pursue intruders, you should
have tools and procedures ready to apply. It is best to work up
these tools and procedures before you need them. Don't wait until
an intruder is on your system to figure out how to track the
intruder's actions; you will be busy enough if an intruder
strikes.
3.8 Communicating Security Policy
Security policies, in order to be effective, must be communicated to
both the users of the system and the system maintainers. This
section describes what these people should be told, and how to tell
them.
3.8.1 Educating the Users
Users should be made aware of how the computer systems are
expected to be used, and how to protect themselves from
unauthorized users.
3.8.1.1 Proper Account/Workstation Use
All users should be informed about what is considered the
"proper" use of their account or workstation ("proper" use is
discussed in section 2.3.2). This can most easily be done at
the time a user receives their account, by giving them a policy
statement. Proper use policies typically dictate things such
as whether or not the account or workstation may be used for
personal activities (such as checkbook balancing or letter
writing), whether profit-making activities are allowed, whether
game playing is permitted, and so on. These policy statements
may also be used to summarize how the computer facility is
licensed and what software licenses are held by the
institution; for example, many universities have educational
licenses which explicitly prohibit commercial uses of the
system. A more complete list of items to consider when writing
a policy statement is given in section 2.3.
3.8.1.2 Account/Workstation Management Procedures
Each user should be told how to properly manage their account
and workstation. This includes explaining how to protect files
stored on the system, how to log out or lock the terminal or
workstation, and so on. Much of this information is typically
covered in the "beginning user" documentation provided by the
operating system vendor, although many sites elect to
supplement this material with local information.
If your site offers dial-up modem access to the computer
systems, special care must be taken to inform users of the
security problems inherent in providing this access. Issues
such as making sure to log out before hanging up the modem
should be covered when the user is initially given dial-up
access.
Likewise, access to the systems via local and wide-area
networks presents its own set of security problems which users
should be made aware of. Files which grant "trusted host" or
"trusted user" status to remote systems and users should be
carefully explained.
3.8.1.3 Determining Account Misuse
Users should be told how to detect unauthorized access to their
account. If the system prints the last login time when a user
logs in, he or she should be told to check that time and note
whether or not it agrees with the last time he or she actually
logged in.
Command interpreters on some systems (e.g., the UNIX C shell)
maintain histories of the last several commands executed.
Users should check these histories to be sure someone has not
executed other commands with their account.
3.8.1.4 Problem Reporting Procedures
A procedure should be developed to enable users to report
suspected misuse of their accounts or other misuse they may
have noticed. This can be done either by providing the name
and telephone number of a system administrator who manages
security of the computer system, or by creating an electronic
mail address (e.g., "security") to which users can address
their problems.
3.8.2 Educating the Host Administrators
In many organizations, computer systems are administered by a wide
variety of people. These administrators must know how to protect
their own systems from attack and unauthorized use, as well as how
to communicate successful penetration of their systems to other
administrators as a warning.
3.8.2.1 Account Management Procedures
Care must be taken when installing accounts on the system in
order to make them secure. When installing a system from
distribution media, the password file should be examined for
"standard" accounts provided by the vendor. Many vendors
provide accounts for use by system services or field service
personnel. These accounts typically have either no password or
one which is common knowledge. These accounts should be given
new passwords if they are needed, or disabled or deleted from
the system if they are not.
Accounts without passwords are generally very dangerous since
they allow anyone to access the system. Even accounts which do
not execute a command interpreter (e.g., accounts which exist
only to see who is logged in to the system) can be compromised
if set up incorrectly. A related concept, that of "anonymous"
file transfer (FTP) [20], allows users from all over the
network to access your system to retrieve files from (usually)
a protected disk area. You should carefully weigh the benefits
that an account without a password provides against the
security risks of providing such access to your system.
If the operating system provides a "shadow" password facility
which stores passwords in a separate file accessible only to
privileged users, this facility should be used. System V UNIX,
SunOS 4.0 and above, and versions of Berkeley UNIX after 4.3BSD
Tahoe, as well as others, provide this feature. It protects
passwords by hiding their encrypted values from unprivileged
users. This prevents an attacker from copying your password
file to his or her machine and then attempting to break the
passwords at his or her leisure.
Keep track of who has access to privileged user accounts (e.g.,
"root" on UNIX or "MAINT" on VMS). Whenever a privileged user
leaves the organization or no longer has need of the privileged
account, the passwords on all privileged accounts should be
changed.
3.8.2.2 Configuration Management Procedures
When installing a system from the distribution media or when
installing third-party software, it is important to check the
installation carefully. Many installation procedures assume a
"trusted" site, and hence will install files with world write
permission enabled, or otherwise compromise the security of
files.
Network services should also be examined carefully when first
installed. Many vendors provide default network permission
files which imply that all outside hosts are to be "trusted",
which is rarely the case when connected to wide-area networks
such as the Internet.
Many intruders collect information on the vulnerabilities of
particular system versions. The older a system, the more
likely it is that there are security problems in that version
which have since been fixed by the vendor in a later release.
For this reason, it is important to weigh the risks of not
upgrading to a new operating system release (thus leaving
security holes unplugged) against the cost of upgrading to the
new software (possibly breaking third-party software, etc.).
Bug fixes from the vendor should be weighed in a similar
fashion, with the added note that "security" fixes from a
vendor usually address fairly serious security problems.
Other bug fixes, received via network mailing lists and the
like, should usually be installed, but not without careful
examination. Never install a bug fix unless you're sure you
know what the consequences of the fix are - there's always the
possibility that an intruder has suggested a "fix" which
actually gives him or her access to your system.
3.8.2.3 Recovery Procedures - Backups
It is impossible to overemphasize the need for a good backup
strategy. File system backups not only protect you in the
event of hardware failure or accidental deletions, but they
also protect you against unauthorized changes made by an
intruder. Without a copy of your data the way it's "supposed"
to be, it can be difficult to undo something an attacker has
done.
Backups, especially if run daily, can also be useful in
providing a history of an intruder's activities. Looking
through old backups can establish when your system was first
penetrated. Intruders may leave files around which, although
deleted later, are captured on the backup tapes. Backups can
also be used to document an intruder's activities to law
enforcement agencies if necessary.
A good backup strategy will dump the entire system to tape at
least once a month. Partial (or "incremental") dumps should be
done at least twice a week, and ideally they should be done
daily. Commands specifically designed for performing file
system backups (e.g., UNIX "dump" or VMS "BACKUP") should be
used in preference to other file copying commands, since these
tools are designed with the express intent of restoring a
system to a known state.
3.8.2.4 Problem Reporting Procedures
As with users, system administrators should have a defined
procedure for reporting security problems. In large
installations, this is often done by creating an electronic
mail alias which contains the names of all system
administrators in the organization. Other methods include
setting up some sort of response team similar to the CERT, or
establishing a "hotline" serviced by an existing support group.
3.9 Resources to Prevent Security Breaches
This section discusses software, hardware, and procedural resources
that can be used to support your site security policy.
3.9.1 Network Connections and Firewalls
A "firewall" is put in place in a building to provide a point of
resistance to the entry of flames into another area. Similarly, a
secretary's desk and reception area provides a point of
controlling access to other office spaces. This same technique
can be applied to a computer site, particularly as it pertains to
network connections.
Some sites will be connected only to other sites within the same
organization and will not have the ability to connect to other
networks. Sites such as these are less susceptible to threats
from outside their own organization, although intrusions may still
occur via paths such as dial-up modems. On the other hand, many
other organizations will be connected to other sites via much
larger networks, such as the Internet. These sites are
susceptible to the entire range of threats associated with a
networked environment.
The risks of connecting to outside networks must be weighed
against the benefits. It may be desirable to limit connection to
outside networks to those hosts which do not store sensitive
material, keeping "vital" machines (such as those which maintain
company payroll or inventory systems) isolated. If there is a
need to participate in a Wide Area Network (WAN), consider
restricting all access to your local network through a single
system. That is, all access to or from your own local network
must be made through a single host computer that acts as a
firewall between you and the outside world. This firewall system
should be rigorously controlled and password protected, and
external users accessing it should also be constrained by
restricting the functionality available to remote users. By using
this approach, your site could relax some of the internal security
controls on your local net, but still be afforded the protection
of a rigorously controlled host front end.
Note that even with a firewall system, compromise of the firewall
could result in compromise of the network behind the firewall.
Work has been done in some areas to construct a firewall which
even when compromised, still protects the local network [6,
CHESWICK].
3.9.2 Confidentiality
Confidentiality, the act of keeping things hidden or secret, is
one of the primary goals of computer security practitioners.
Several mechanisms are provided by most modern operating systems
to enable users to control the dissemination of information.
Depending upon where you work, you may have a site where
everything is protected, or a site where all information is
usually regarded as public, or something in-between. Most sites
lean toward the in-between, at least until some penetration has
occurred.
Generally, there are three instances in which information is
vulnerable to disclosure: when the information is stored on a
computer system, when the information is in transit to another
system (on the network), and when the information is stored on
backup tapes.
The first of these cases is controlled by file permissions, access
control lists, and other similar mechanisms. The last can be
controlled by restricting access to the backup tapes (by locking
them in a safe, for example). All three cases can be helped by
using encryption mechanisms.
3.9.2.1 Encryption (hardware and software)
Encryption is the process of taking information that exists in
some readable form and converting it into a non-readable form.
There are several types of commercially available encryption
packages in both hardware and software forms. Hardware
encryption engines have the advantage that they are much faster
than the software equivalent, yet because they are faster, they
are of greater potential benefit to an attacker who wants to
execute a brute-force attack on your encrypted information.
The advantage of using encryption is that, even if other access
control mechanisms (passwords, file permissions, etc.) are
compromised by an intruder, the data is still unusable.
Naturally, encryption keys and the like should be protected at
least as well as account passwords.
Information in transit (over a network) may be vulnerable to
interception as well. Several solutions to this exist, ranging
from simply encrypting files before transferring them (end-to-
end encryption) to special network hardware which encrypts
everything it sends without user intervention (secure links).
The Internet as a whole does not use secure links, thus end-
to-end encryption must be used if encryption is desired across
the Internet.
3.9.2.1.1 Data Encryption Standard (DES)
DES is perhaps the most widely used data encryption
mechanism today. Many hardware and software implementations
exist, and some commercial computers are provided with a
software version. DES transforms plain text information
into encrypted data (or ciphertext) by means of a special
algorithm and "seed" value called a key. So long as the key
is retained (or remembered) by the original user, the
ciphertext can be restored to the original plain text.
One of the pitfalls of all encryption systems is the need to
remember the key under which a thing was encrypted (this is
not unlike the password problem discussed elsewhere in this
document). If the key is written down, it becomes less
secure. If forgotten, there is little (if any) hope of
recovering the original data.
Most UNIX systems provide a DES command that enables a user
to encrypt data using the DES algorithm.
3.9.2.1.2 Crypt
Similar to the DES command, the UNIX "crypt" command allows
a user to encrypt data. Unfortunately, the algorithm used
by "crypt" is very insecure (based on the World War II
"Enigma" device), and files encrypted with this command can
be decrypted easily in a matter of a few hours. Generally,
use of the "crypt" command should be avoided for any but the
most trivial encryption tasks.
3.9.2.2 Privacy Enhanced Mail
Electronic mail normally transits the network in the clear
(i.e., anyone can read it). This is obviously not the optimal
solution. Privacy enhanced mail provides a means to
automatically encrypt electronic mail messages so that a person
eavesdropping at a mail distribution node is not (easily)
capable of reading them. Several privacy enhanced mail
packages are currently being developed and deployed on the
Internet.
The Internet Activities Board Privacy Task Force has defined a
draft standard, elective protocol for use in implementing
privacy enhanced mail. This protocol is defined in RFCs 1113,
1114, and 1115 [7,8,9]. Please refer to the current edition of
the "IAB Official Protocol Standards" (currently, RFC1200
[21]) for the standardization state and status of these
protocols.
3.9.3 Origin Authentication
We mostly take it on faith that the header of an electronic mail
message truly indicates the originator of a message. However, it
iseasy to "spoof", or forge the source of a mail message. Origin
authentication provides a means to be certain of the originator of
a message or other object in the same way that a Notary Public
assures a signature on a legal document. This is done by means of
a "Public Key" cryptosystem.
A public key cryptosystem differs from a private key cryptosystem
in several ways. First, a public key system uses two keys, a
Public Key that anyone can use (hence the name) and a Private Key
that only the originator of a message uses. The originator uses
the private key to encrypt the message (as in DES). The receiver,
who has obtained the public key for the originator, may then
decrypt the message.
In this scheme, the public key is used to authenticate the
originator's use of his or her private key, and hence the identity
of the originator is more rigorously proven. The most widely
known implementation of a public key cryptosystem is the RSA
system [26]. The Internet standard for privacy enhanced mail
makes use of the RSA system.
3.9.4 Information Integrity
Information integrity refers to the state of information such that
it is complete, correct, and unchanged from the last time in which
it was verified to be in an "integral" state. The value of
information integrity to a site will vary. For example, it is
more important for military and government installations to
prevent the "disclosure" of classified information, whether it is
right or wrong. A bank, on the other hand, is far more concerned
with whether the account information maintained for its customers
is complete and accurate.
Numerous computer system mechanisms, as well as procedural
controls, have an influence on the integrity of system
information. Traditional access control mechanisms maintain
controls over who can access system information. These mechanisms
alone are not sufficient in some cases to provide the degree of
integrity required. Some other mechanisms are briefly discussed
below.
It should be noted that there are other aspects to maintaining
system integrity besides these mechanisms, such as two-person
controls, and integrity validation procedures. These are beyond
the scope of this document.
3.9.4.1 Checksums
Easily the simplest mechanism, a simple checksum routine can
compute a value for a system file and compare it with the last
known value. If the two are equal, the file is probably
unchanged. If not, the file has been changed by some unknown
means.
Though it is the easiest to implement, the checksum scheme
suffers from a serious failing in that it is not very
sophisticated and a determined attacker could easily add enough
characters to the file to eventually obtain the correct value.
A specific type of checksum, called a CRC checksum, is
considerably more robust than a simple checksum. It is only
slightly more difficult to implement and provides a better
degree of catching errors. It too, however, suffers from the
possibility of compromise by an attacker.
Checksums may be used to detect the altering of information.
However, they do not actively guard against changes being made.
For this, other mechanisms such as access controls and
encryption should be used.
3.9.4.2 Cryptographic Checksums
Cryptographic checksums (also called cryptosealing) involve
breaking a file up into smaller chunks, calculating a (CRC)
checksum for each chunk, and adding the CRCs together.
Depending upon the exact algorithm used, this can result in a
nearly unbreakable method of determining whether a file has
been changed. This mechanism suffers from the fact that it is
sometimes computationally intensive and may be prohibitive
except in cases where the utmost integrity protection is
desired.
Another related mechanism, called a one-way hash function (or a
Manipulation Detection Code (MDC)) can also be used to uniquely
identify a file. The idea behind these functions is that no
two inputs can produce the same output, thus a modified file
will not have the same hash value. One-way hash functions can
be implemented efficiently on a wide variety of systems, making
unbreakable integrity checks possible. (Snefru, a one-way hash
function available via USENET as well as the Internet is just
one example of an efficient one-way hash function.) [10]
3.9.5 Limiting Network Access
The dominant network protocols in use on the Internet, IP (RFC
791) [11], TCP (RFC793) [12], and UDP (RFC768) [13], carry
certain control information which can be used to restrict access
to certain hosts or networks within an organization.
The IP packet header contains the network addresses of both the
sender and recipient of the packet. Further, the TCP and UDP
protocols provide the notion of a "port", which identifies the
endpoint (usually a network server) of a communications path. In
some instances, it may be desirable to deny access to a specific
TCP or UDP port, or even to certain hosts and networks altogether.
3.9.5.1 Gateway Routing Tables
One of the simplest approaches to preventing unwanted network
connections is to simply remove certain networks from a
gateway's routing tables. This makes it "impossible" for a
host to send packets to these networks. (Most protocols
require bidirectional packet flow even for unidirectional data
flow, thus breaking one side of the route is usually
sufficient.)
This approach is commonly taken in "firewall" systems by
preventing the firewall from advertising local routes to the
outside world. The approach is deficient in that it often
prevents "too much" (e.g., in order to prevent access to one
system on the network, access to all systems on the network is
disabled).
3.9.5.2 Router Packet Filtering
Many commercially available gateway systems (more correctly
called routers) provide the ability to filter packets based not
only on sources or destinations, but also on source-destination
combinations. This mechanism can be used to deny access to a
specific host, network, or subnet from any other host, network,
or subnet.
Gateway systems from some vendors (e.g., cisco Systems) support
an even more complex scheme, allowing finer control over source
and destination addresses. Via the use of address masks, one
can deny access to all but one host on a particular network.
The cisco Systems also allow packet screening based on IP
protocol type and TCP or UDP port numbers [14].
This can also be circumvented by "source routing" packets
destined for the "secret" network. Source routed packets may
be filtered out by gateways, but this may restrict other
legitimate activities, such as diagnosing routing problems.
3.9.6 Authentication Systems
Authentication refers to the process of proving a claimed identity
to the satisfaction of some permission-granting authority.
Authentication systems are hardware, software, or procedural
mechanisms that enable a user to obtain access to computing
resources. At the simplest level, the system administrator who
adds new user accounts to the system is part of the system
authentication mechanism. At the other end of the spectrum,
fingerprint readers or retinal scanners provide a very high-tech
solution to establishing a potential user's identity. Without
establishing and proving a user's identity prior to establishing a
session, your site's computers are vulnerable to any sort of
attack.
Typically, a user authenticates himself or herself to the system
by entering a password in response to a prompt.
Challenge/Response mechanisms improve upon passwords by prompting
the user for some piece of information shared by both the computer
and the user (such as mother's maiden name, etc.).
3.9.6.1 Kerberos
Kerberos, named after the dog who in mythology is said to stand
at the gates of Hades, is a collection of software used in a
large network to establish a user's claimed identity.
Developed at the Massachusetts Institute of Technology (MIT),
it uses a combination of encryption and distributed databases
so that a user at a campus facility can login and start a
session from any computer located on the campus. This has
clear advantages in certain environments where there are a
large number of potential users who may establish a connection
from any one of a large number of workstations. Some vendors
are now incorporating Kerberos into their systems.
It should be noted that while Kerberos makes several advances
in the area of authentication, some security weaknesses in the
protocol still remain [15].
3.9.6.2 Smart Cards
Several systems use "smart cards" (a small calculator-like
device) to help authenticate users. These systems depend on
the user having an object in their possession. One such system
involves a new password procedure that require a user to enter
a value obtained from a "smart card" when asked for a password
by the computer. Typically, the host machine will give the
user some piece of information that is entered into the
keyboard of the smart card. The smart card will display a
response which must then be entered into the computer before
the session will be established. Another such system involves
a smart card which displays a number which changes over time,
but which is synchronized with the authentication software on
the computer.
This is a better way of dealing with authentication than with
the traditional password approach. On the other hand, some say
it's inconvenient to carry the smart card. Start-up costs are
likely to be high as well.
3.9.7 Books, Lists, and Informational Sources
There are many good sources for information regarding computer
security. The annotated bibliography at the end of this document
can provide you with a good start. In addition, information can
be obtained from a variety of other sources, some of which are
described in this section.
3.9.7.1 Security Mailing Lists
The UNIX Security mailing list exists to notify system
administrators of security problems before they become common
knowledge, and to provide security enhancement information. It
is a restricted-access list, open only to people who can be
verified as being principal systems people at a site. Requests
to join the list must be sent by either the site contact listed
in the Defense Data Network's Network Information Center's (DDN
NIC) WHOIS database, or from the "root" account on one of the
major site machines. You must include the destination address
you want on the list, an indication of whether you want to be
on the mail reflector list or receive weekly digests, the
electronic mail address and voice telephone number of the site
contact if it isn't you, and the name, address, and telephone
number of your organization. This information should be sent
to SECURITY-REQUEST@CPD.COM.
The RISKS digest is a component of the ACM Committee on
Computers and Public Policy, moderated by Peter G. Neumann. It
is a discussion forum on risks to the public in computers and
related systems, and along with discussing computer security
and privacy issues, has discussed such subjects as the Stark
incident, the shooting down of the Iranian airliner in the
Persian Gulf (as it relates to the computerized weapons
systems), problems in air and railroad traffic control systems,
software engineering, and so on. To join the mailing list,
send a message to RISKS-REQUEST@CSL.SRI.COM. This list is also
available in the USENET newsgroup "comp.risks".
The VIRUS-L list is a forum for the discussion of computer
virus experiences, protection software, and related topics.
The list is open to the public, and is implemented as a
moderated digest. Most of the information is related to
personal computers, although some of it may be applicable to
larger systems. To subscribe, send the line:
SUB VIRUS-L your full name
to the address LISTSERV%LEHIIBM1.BITNET@MITVMA.MIT.EDU. This
list is also available via the USENET newsgroup "comp.virus".
The Computer Underground Digest "is an open forum dedicated to
sharing information among computerists and to the presentation
and debate of diverse views." While not directly a security
list, it does contain discussions about privacy and other
security related topics. The list can be read on USENET as
alt.society.cu-digest, or to join the mailing list, send mail
to Gordon Myer (TK0JUT2%NIU.bitnet@mitvma.mit.edu).
Submissions may be mailed to: cud@chinacat.unicom.com.
3.9.7.2 Networking Mailing Lists
The TCP-IP mailing list is intended to act as a discussion
forum for developers and maintainers of implementations of the
TCP/IP protocol suite. It also discusses network-related
security problems when they involve programs providing network
services, such as "Sendmail". To join the TCP-IP list, send a
message to TCP-IP-REQUEST@NISC.SRI.COM. This list is also
available in the USENET newsgroup "comp.protocols.tcp-ip".
SUN-NETS is a discussion list for items pertaining to
networking on Sun systems. Much of the discussion is related
to NFS, NIS (formally Yellow Pages), and name servers. To
subscribe, send a message to SUN-NETS-REQUEST@UMIACS.UMD.EDU.
The USENET groups misc.security and alt.security also discuss
security issues. misc.security is a moderated group and also
includes discussions of physical security and locks.
alt.security is unmoderated.
3.9.7.3 Response Teams
Several organizations have formed special groups of people to
deal with computer security problems. These teams collect
information about possible security holes and disseminate it to
the proper people, track intruders, and assist in recovery from
security violations. The teams typically have both electronic
mail distribution lists as well as a special telephone number
which can be called for information or to report a problem.
Many of these teams are members of the CERT System, which is
coordinated by the National Institute of Standards and
Technology (NIST), and exists to facilitate the exchange of
information between the various teams.
3.9.7.3.1 DARPA Computer Emergency Response Team
The Computer Emergency Response Team/Coordination Center
(CERT/CC) was established in December 1988 by the Defense
Advanced Research Projects Agency (DARPA) to address
computer security concerns of research users of the
Internet. It is operated by the Software Engineering
Institute (SEI) at Carnegie-Mellon University (CMU). The
CERT can immediately confer with experts to diagnose and
solve security problems, and also establish and maintain
communications with the affected computer users and
government authorities as appropriate.
The CERT/CC serves as a clearing house for the
identification and repair of security vulnerabilities,
informal assessments of existing systems, improvement of
emergency response capability, and both vendor and user
security awareness. In addition, the team works with
vendors of various systems in order to coordinate the fixes
for security problems.
The CERT/CC sends out security advisories to the CERT-
ADVISORY mailing list whenever appropriate. They also
operate a 24-hour hotline that can be called to report
security problems (e.g., someone breaking into your system),
as well as to obtain current (and accurate) information