be clear that: the security server should not be accessible from
off-site; should offer minimum access, except for the authentication
function, to users on-site; and should not be co-located with any
other servers. Further, all access to the node, including access to
the service itself, should be logged to provide a "paper trail" in
the event of a security breach.
3.3 Firewalls
One of the most widely deployed and publicized security measures in
use on the Internet is a "firewall." Firewalls have been given the
reputation of a general panacea for many, if not all, of the Internet
security issues. They are not. Firewalls are just another tool in
the quest for system security. They provide a certain level of
protection and are, in general, a way of implementing security policy
at the network level. The level of security that a firewall provides
can vary as much as the level of security on a particular machine.
There are the traditional trade-offs between security, ease of use,
cost, complexity, etc.
A firewall is any one of several mechanisms used to control and watch
access to and from a network for the purpose of protecting it. A
firewall acts as a gateway through which all traffic to and from the
protected network and/or systems passes. Firewalls help to place
limitations on the amount and type of communication that takes place
between the protected network and the another network (e.g., the
Internet, or another piece of the site's network).
A firewall is generally a way to build a wall between one part of a
network, a company's internal network, for example, and another part,
the global Internet, for example. The unique feature about this wall
is that there needs to be ways for some traffic with particular
characteristics to pass through carefully monitored doors
("gateways"). The difficult part is establishing the criteria by
which the packets are allowed or denied access through the doors.
Books written on firewalls use different terminology to describe the
various forms of firewalls. This can be confusing to system
administrators who are not familiar with firewalls. The thing to note
here is that there is no fixed terminology for the description of
firewalls.
Firewalls are not always, or even typically, a single machine.
Rather, firewalls are often a combination of routers, network
segments, and host computers. Therefore, for the purposes of this
discussion, the term "firewall" can consist of more than one physical
device. Firewalls are typically built using two different
components, filtering routers and proxy servers.
Filtering routers are the easiest component to conceptualize in a
firewall. A router moves data back and forth between two (or more)
different networks. A "normal" router takes a packet from network A
and "routes" it to its destination on network B. A filtering router
does the same thing but decides not only how to route the packet, but
whether it should route the packet. This is done by installing a
series of filters by which the router decides what to do with any
given packet of data.
A discussion concerning capabilities of a particular brand of router,
running a particular software version is outside the scope of this
document. However, when evaluating a router to be used for filtering
packets, the following criteria can be important when implementing a
filtering policy: source and destination IP address, source and
destination TCP port numbers, state of the TCP "ack" bit, UDP source
and destination port numbers, and direction of packet flow (i.e.. A-
>B or B->A). Other information necessary to construct a secure
filtering scheme are whether the router reorders filter instructions
(designed to optimize filters, this can sometimes change the meaning
and cause unintended access), and whether it is possible to apply
filters for inbound and outbound packets on each interface (if the
router filters only outbound packets then the router is "outside" of
its filters and may be more vulnerable to attack). In addition to
the router being vulnerable, this distinction between applying
filters on inbound or outbound packets is especially relevant for
routers with more than 2 interfaces. Other important issues are the
ability to create filters based on IP header options and the fragment
state of a packet. Building a good filter can be very difficult and
requires a good understanding of the type of services (protocols)
that will be filtered.
For better security, the filters usually restrict access between the
two connected nets to just one host, the bastion host. It is only
possible to access the other network via this bastion host. As only
this host, rather than a few hundred hosts, can get attacked, it is
easier to maintain a certain level of security because only this host
has to be protected very carefully. To make resources available to
legitimate users across this firewall, services have to be forwarded
by the bastion host. Some servers have forwarding built in (like
DNS-servers or SMTP-servers), for other services (e.g., Telnet, FTP,
etc.), proxy servers can be used to allow access to the resources
across the firewall in a secure way.
A proxy server is way to concentrate application services through a
single machine. There is typically a single machine (the bastion
host) that acts as a proxy server for a variety of protocols (Telnet,
SMTP, FTP, HTTP, etc.) but there can be individual host computers for
each service. Instead of connecting directly to an external server,
the client connects to the proxy server which in turn initiates a
connection to the requested external server. Depending on the type
of proxy server used, it is possible to configure internal clients to
perform this redirection automatically, without knowledge to the
user, others might require that the user connect directly to the
proxy server and then initiate the connection through a specified
format.
There are significant security benefits which can be derived from
using proxy servers. It is possible to add access control lists to
protocols, requiring users or systems to provide some level of
authentication before access is granted. Smarter proxy servers,
sometimes called Application Layer Gateways (ALGs), can be written
which understand specific protocols and can be configured to block
only subsections of the protocol. For example, an ALG for FTP can
tell the difference between the "put" command and the "get" command;
an organization may wish to allow users to "get" files from the
Internet, but not be able to "put" internal files on a remote server.
By contrast, a filtering router could either block all FTP access, or
none, but not a subset.
Proxy servers can also be configured to encrypt data streams based on
a variety of parameters. An organization might use this feature to
allow encrypted connections between two locations whose sole access
points are on the Internet.
Firewalls are typically thought of as a way to keep intruders out,
but they are also often used as a way to let legitimate users into a
site. There are many examples where a valid user might need to
regularly access the "home" site while on travel to trade shows and
conferences, etc. Access to the Internet is often available but may
be through an untrusted machine or network. A correctly configured
proxy server can allow the correct users into the site while still
denying access to other users.
The current best effort in firewall techniques is found using a
combination of a pair of screening routers with one or more proxy
servers on a network between the two routers. This setup allows the
external router to block off any attempts to use the underlying IP
layer to break security (IP spoofing, source routing, packet
fragments), while allowing the proxy server to handle potential
security holes in the higher layer protocols. The internal router's
purpose is to block all traffic except to the proxy server. If this
setup is rigidly implemented, a high level of security can be
achieved.
Most firewalls provide logging which can be tuned to make security
administration of the network more convenient. Logging may be
centralized and the system may be configured to send out alerts for
abnormal conditions. It is important to regularly monitor these logs
for any signs of intrusions or break-in attempts. Since some
intruders will attempt to cover their tracks by editing logs, it is
desirable to protect these logs. A variety of methods is available,
including: write once, read many (WORM) drives; papers logs; and
centralized logging via the "syslog" utility. Another technique is
to use a "fake" serial printer, but have the serial port connected to
an isolated machine or PC which keeps the logs.
Firewalls are available in a wide range of quality and strengths.
Commercial packages start at approximately $10,000US and go up to
over $250,000US. "Home grown" firewalls can be built for smaller
amounts of capital. It should be remembered that the correct setup
of a firewall (commercial or homegrown) requires a significant amount
of skill and knowledge of TCP/IP. Both types require regular
maintenance, installation of software patches and updates, and
regular monitoring. When budgeting for a firewall, these additional
costs should be considered in addition to the cost of the physical
elements of the firewall.
As an aside, building a "home grown" firewall requires a significant
amount of skill and knowledge of TCP/IP. It should not be trivially
attempted because a perceived sense of security is worse in the long
run than knowing that there is no security. As with all security
measures, it is important to decide on the threat, the value of the
assets to be protected, and the costs to implement security.
A final note about firewalls. They can be a great aid when
implementing security for a site and they protect against a large
variety of attacks. But it is important to keep in mind that they
are only one part of the solution. They cannot protect your site
against all types of attack.
4. Security Services and Procedures
This chapter guides the reader through a number of topics that should
be addressed when securing a site. Each section touches on a
security service or capability that may be required to protect the
information and systems at a site. The topics are presented at a
fairly high-level to introduce the reader to the concepts.
Throughout the chapter, you will find significant mention of
cryptography. It is outside the scope of this document to delve into
details concerning cryptography, but the interested reader can obtain
more information from books and articles listed in the reference
section of this document.
4.1 Authentication
For many years, the prescribed method for authenticating users has
been through the use of standard, reusable passwords. Originally,
these passwords were used by users at terminals to authenticate
themselves to a central computer. At the time, there were no
networks (internally or externally), so the risk of disclosure of the
clear text password was minimal. Today, systems are connected
together through local networks, and these local networks are further
connected together and to the Internet. Users are logging in from
all over the globe; their reusable passwords are often transmitted
across those same networks in clear text, ripe for anyone in-between
to capture. And indeed, the CERT* Coordination Center and other
response teams are seeing a tremendous number of incidents involving
packet sniffers which are capturing the clear text passwords.
With the advent of newer technologies like one-time passwords (e.g.,
S/Key), PGP, and token-based authentication devices, people are using
password-like strings as secret tokens and pins. If these secret
tokens and pins are not properly selected and protected, the
authentication will be easily subverted.
4.1.1 One-Time passwords
As mentioned above, given today's networked environments, it is
recommended that sites concerned about the security and integrity of
their systems and networks consider moving away from standard,
reusable passwords. There have been many incidents involving Trojan
network programs (e.g., telnet and rlogin) and network packet
sniffing programs. These programs capture clear text
hostname/account name/password triplets. Intruders can use the
captured information for subsequent access to those hosts and
accounts. This is possible because 1) the password is used over and
over (hence the term "reusable"), and 2) the password passes across
the network in clear text.
Several authentication techniques have been developed that address
this problem. Among these techniques are challenge-response
technologies that provide passwords that are only used once (commonly
called one-time passwords). There are a number of products available
that sites should consider using. The decision to use a product is
the responsibility of each organization, and each organization should
perform its own evaluation and selection.
4.1.2 Kerberos
Kerberos is a distributed network security system which provides for
authentication across unsecured networks. If requested by the
application, integrity and encryption can also be provided. Kerberos
was originally developed at the Massachusetts Institute of Technology
(MIT) in the mid 1980s. There are two major releases of Kerberos,
version 4 and 5, which are for practical purposes, incompatible.
Kerberos relies on a symmetric key database using a key distribution
center (KDC) which is known as the Kerberos server. A user or
service (known as "principals") are granted electronic "tickets"
after properly communicating with the KDC. These tickets are used
for authentication between principals. All tickets include a time
stamp which limits the time period for which the ticket is valid.
Therefore, Kerberos clients and server must have a secure time
source, and be able to keep time accurately.
The practical side of Kerberos is its integration with the
application level. Typical applications like FTP, telnet, POP, and
NFS have been integrated with the Kerberos system. There are a
variety of implementations which have varying levels of integration.
Please see the Kerberos FAQ available at http://www.ov.com/misc/krb-
faq.html for the latest information.
4.1.3 Choosing and Protecting Secret Tokens and PINs
When selecting secret tokens, take care to choose them carefully.
Like the selection of passwords, they should be robust against brute
force efforts to guess them. That is, they should not be single
words in any language, any common, industry, or cultural acronyms,
etc. Ideally, they will be longer rather than shorter and consist of
pass phrases that combine upper and lower case character, digits, and
other characters.
Once chosen, the protection of these secret tokens is very important.
Some are used as pins to hardware devices (like token cards) and
these should not be written down or placed in the same location as
the device with which they are associated. Others, such as a secret
Pretty Good Privacy (PGP) key, should be protected from unauthorized
access.
One final word on this subject. When using cryptography products,
like PGP, take care to determine the proper key length and ensure
that your users are trained to do likewise. As technology advances,
the minimum safe key length continues to grow. Make sure your site
keeps up with the latest knowledge on the technology so that you can
ensure that any cryptography in use is providing the protection you
believe it is.
4.1.4 Password Assurance
While the need to eliminate the use of standard, reusable passwords
cannot be overstated, it is recognized that some organizations may
still be using them. While it's recommended that these organizations
transition to the use of better technology, in the mean time, we have
the following advice to help with the selection and maintenance of
traditional passwords. But remember, none of these measures provides
protection against disclosure due to sniffer programs.
(1) The importance of robust passwords - In many (if not most) cases
of system penetration, the intruder needs to gain access to an
account on the system. One way that goal is typically
accomplished is through guessing the password of a legitimate
user. This is often accomplished by running an automated
password cracking program, which utilizes a very large
dictionary, against the system's password file. The only way to
guard against passwords being disclosed in this manner is
through the careful selection of passwords which cannot be
easily guessed (i.e., combinations of numbers, letters, and
punctuation characters). Passwords should also be as long as
the system supports and users can tolerate.
(2) Changing default passwords - Many operating systems and
application programs are installed with default accounts and
passwords. These must be changed immediately to something that
cannot be guessed or cracked.
(3) Restricting access to the password file - In particular, a site
wants to protect the encrypted password portion of the file so
that would-be intruders don't have them available for cracking.
One effective technique is to use shadow passwords where the
password field of the standard file contains a dummy or false
password. The file containing the legitimate passwords are
protected elsewhere on the system.
(4) Password aging - When and how to expire passwords is still a
subject of controversy among the security community. It is
generally accepted that a password should not be maintained once
an account is no longer in use, but it is hotly debated whether
a user should be forced to change a good password that's in
active use. The arguments for changing passwords relate to the
prevention of the continued use of penetrated accounts.
However, the opposition claims that frequent password changes
lead to users writing down their passwords in visible areas
(such as pasting them to a terminal), or to users selecting very
simple passwords that are easy to guess. It should also be
stated that an intruder will probably use a captured or guessed
password sooner rather than later, in which case password aging
provides little if any protection.
While there is no definitive answer to this dilemma, a password
policy should directly address the issue and provide guidelines
for how often a user should change the password. Certainly, an
annual change in their password is usually not difficult for
most users, and you should consider requiring it. It is
recommended that passwords be changed at least whenever a
privileged account is compromised, there is a critical change in
personnel (especially if it is an administrator!), or when an
account has been compromised. In addition, if a privileged
account password is compromised, all passwords on the system
should be changed.
(5) Password/account blocking - Some sites find it useful to disable
accounts after a predefined number of failed attempts to
authenticate. If your site decides to employ this mechanism, it
is recommended that the mechanism not "advertise" itself. After
disabling, even if the correct password is presented, the
message displayed should remain that of a failed login attempt.
Implementing this mechanism will require that legitimate users
contact their system administrator to request that their account
be reactivated.
(6) A word about the finger daemon - By default, the finger daemon
displays considerable system and user information. For example,
it can display a list of all users currently using a system, or
all the contents of a specific user's .plan file. This
information can be used by would-be intruders to identify
usernames and guess their passwords. It is recommended that
sites consider modifying finger to restrict the information
displayed.
4.2 Confidentiality
There will be information assets that your site will want to protect
from disclosure to unauthorized entities. Operating systems often
have built-in file protection mechanisms that allow an administrator
to control who on the system can access, or "see," the contents of a
given file. A stronger way to provide confidentiality is through
encryption. Encryption is accomplished by scrambling data so that it
is very difficult and time consuming for anyone other than the
authorized recipients or owners to obtain the plain text. Authorized
recipients and the owner of the information will possess the
corresponding decryption keys that allow them to easily unscramble
the text to a readable (clear text) form. We recommend that sites
use encryption to provide confidentiality and protect valuable
information.
The use of encryption is sometimes controlled by governmental and
site regulations, so we encourage administrators to become informed
of laws or policies that regulate its use before employing it. It is
outside the scope of this document to discuss the various algorithms
and programs available for this purpose, but we do caution against
the casual use of the UNIX crypt program as it has been found to be
easily broken. We also encourage everyone to take time to understand
the strength of the encryption in any given algorithm/product before
using it. Most well-known products are well-documented in the
literature, so this should be a fairly easy task.
4.3 Integrity
As an administrator, you will want to make sure that information
(e.g., operating system files, company data, etc.) has not been
altered in an unauthorized fashion. This means you will want to
provide some assurance as to the integrity of the information on your
systems. One way to provide this is to produce a checksum of the
unaltered file, store that checksum offline, and periodically (or
when desired) check to make sure the checksum of the online file
hasn't changed (which would indicate the data has been modified).
Some operating systems come with checksumming programs, such as the
UNIX sum program. However, these may not provide the protection you
actually need. Files can be modified in such a way as to preserve
the result of the UNIX sum program! Therefore, we suggest that you
use a cryptographically strong program, such as the message digesting
program MD5 [ref], to produce the checksums you will be using to
assure integrity.
There are other applications where integrity will need to be assured,
such as when transmitting an email message between two parties. There
are products available that can provide this capability. Once you
identify that this is a capability you need, you can go about
identifying technologies that will provide it.
4.4 Authorization
Authorization refers to the process of granting privileges to
processes and, ultimately, users. This differs from authentication
in that authentication is the process used to identify a user. Once
identified (reliably), the privileges, rights, property, and
permissible actions of the user are determined by authorization.
Explicitly listing the authorized activities of each user (and user
process) with respect to all resources (objects) is impossible in a
reasonable system. In a real system certain techniques are used to
simplify the process of granting and checking authorization(s).
One approach, popularized in UNIX systems, is to assign to each
object three classes of user: owner, group and world. The owner is
either the creator of the object or the user assigned as owner by the
super-user. The owner permissions (read, write and execute) apply
only to the owner. A group is a collection of users which share
access rights to an object. The group permissions (read, write and
execute) apply to all users in the group (except the owner). The
world refers to everybody else with access to the system. The world
permissions (read, write and execute) apply to all users (except the
owner and members of the group).
Another approach is to attach to an object a list which explicitly
contains the identity of all permitted users (or groups). This is an
Access Control List (ACL). The advantage of ACLs are that they are
easily maintained (one central list per object) and it's very easy to
visually check who has access to what. The disadvantages are the
extra resources required to store such lists, as well as the vast
number of such lists required for large systems.
4.5 Access
4.5.1 Physical Access
Restrict physical access to hosts, allowing access only to those
people who are supposed to use the hosts. Hosts include "trusted"
terminals (i.e., terminals which allow unauthenticated use such as
system consoles, operator terminals and terminals dedicated to
special tasks), and individual microcomputers and workstations,
especially those connected to your network. Make sure people's work
areas mesh well with access restrictions; otherwise they will find
ways to circumvent your physical security (e.g., jamming doors open).
Keep original and backup copies of data and programs safe. Apart
from keeping them in good condition for backup purposes, they must be
protected from theft. It is important to keep backups in a separate
location from the originals, not only for damage considerations, but
also to guard against thefts.
Portable hosts are a particular risk. Make sure it won't cause
problems if one of your staff's portable computer is stolen.
Consider developing guidelines for the kinds of data that should be
allowed to reside on the disks of portable computers as well as how
the data should be protected (e.g., encryption) when it is on a
portable computer.
Other areas where physical access should be restricted is the wiring
closets and important network elements like file servers, name server
hosts, and routers.
4.5.2 Walk-up Network Connections
By "walk-up" connections, we mean network connection points located
to provide a convenient way for users to connect a portable host to
your network.
Consider whether you need to provide this service, bearing in mind
that it allows any user to attach an unauthorized host to your
network. This increases the risk of attacks via techniques such as
IP address spoofing, packet sniffing, etc. Users and site management
must appreciate the risks involved. If you decide to provide walk-up
connections, plan the service carefully and define precisely where
you will provide it so that you can ensure the necessary physical
access security.
A walk-up host should be authenticated before its user is permitted
to access resources on your network. As an alternative, it may be
possible to control physical access. For example, if the service is
to be used by students, you might only provide walk-up connection
sockets in student laboratories.
If you are providing walk-up access for visitors to connect back to
their home networks (e.g., to read e-mail, etc.) in your facility,
consider using a separate subnet that has no connectivity to the
internal network.
Keep an eye on any area that contains unmonitored access to the
network, such as vacant offices. It may be sensible to disconnect
such areas at the wiring closet, and consider using secure hubs and
monitoring attempts to connect unauthorized hosts.
4.5.3 Other Network Technologies
Technologies considered here include X.25, ISDN, SMDS, DDS and Frame
Relay. All are provided via physical links which go through
telephone exchanges, providing the potential for them to be diverted.
Crackers are certainly interested in telephone switches as well as in
data networks!
With switched technologies, use Permanent Virtual Circuits or Closed
User Groups whenever this is possible. Technologies which provide
authentication and/or encryption (such as IPv6) are evolving rapidly;
consider using them on links where security is important.
4.5.4 Modems
4.5.4.1 Modem Lines Must Be Managed
Although they provide convenient access to a site for its users, they
can also provide an effective detour around the site's firewalls.
For this reason it is essential to maintain proper control of modems.
Don't allow users to install a modem line without proper
authorization. This includes temporary installations (e.g., plugging
a modem into a facsimile or telephone line overnight).
Maintain a register of all your modem lines and keep your register up
to date. Conduct regular (ideally automated) site checks for
unauthorized modems.
4.5.4.2 Dial-in Users Must Be Authenticated
A username and password check should be completed before a user can
access anything on your network. Normal password security
considerations are particularly important (see section 4.1.1).
Remember that telephone lines can be tapped, and that it is quite
easy to intercept messages to cellular phones. Modern high-speed
modems use more sophisticated modulation techniques, which makes them
somewhat more difficult to monitor, but it is prudent to assume that
hackers know how to eavesdrop on your lines. For this reason, you
should use one-time passwords if at all possible.
It is helpful to have a single dial-in point (e.g., a single large
modem pool) so that all users are authenticated in the same way.
Users will occasionally mis-type a password. Set a short delay - say
two seconds - after the first and second failed logins, and force a
disconnect after the third. This will slow down automated password
attacks. Don't tell the user whether the username, the password, or
both, were incorrect.
4.5.4.3 Call-back Capability
Some dial-in servers offer call-back facilities (i.e., the user dials
in and is authenticated, then the system disconnects the call and
calls back on a specified number). Call-back is useful since if
someone were to guess a username and password, they are disconnected,
and the system then calls back the actual user whose password was
cracked; random calls from a server are suspicious, at best. This
does mean users may only log in from one location (where the server
is configured to dial them back), and of course there may be phone
charges associated with there call-back location.
This feature should be used with caution; it can easily be bypassed.
At a minimum, make sure that the return call is never made from the
same modem as the incoming one. Overall, although call-back can
improve modem security, you should not depend on it alone.
4.5.4.4 All Logins Should Be Logged
All logins, whether successful or unsuccessful should be logged.
However, do not keep correct passwords in the log. Rather, log them
simply as a successful login attempt. Since most bad passwords are
mistyped by authorized users, they only vary by a single character
from the actual password. Therefore if you can't keep such a log
secure, don't log it at all.
If Calling Line Identification is available, take advantage of it by
recording the calling number for each login attempt. Be sensitive to
the privacy issues raised by Calling Line Identification. Also be
aware that Calling Line Identification is not to be trusted (since
intruders have been known to break into phone switches and forward
phone numbers or make other changes); use the data for informational
purposes only, not for authentication.
4.5.4.5 Choose Your Opening Banner Carefully
Many sites use a system default contained in a message of the day
file for their opening banner. Unfortunately, this often includes the
type of host hardware or operating system present on the host. This
can provide valuable information to a would-be intruder. Instead,
each site should create its own specific login banner, taking care to
only include necessary information.
Display a short banner, but don't offer an "inviting" name (e.g.,
University of XYZ, Student Records System). Instead, give your site
name, a short warning that sessions may be monitored, and a
username/password prompt. Verify possible legal issues related to
the text you put into the banner.
For high-security applications, consider using a "blind" password
(i.e., give no response to an incoming call until the user has typed
in a password). This effectively simulates a dead modem.
4.5.4.6 Dial-out Authentication
Dial-out users should also be authenticated, particularly since your
site will have to pay their telephone charges.
Never allow dial-out from an unauthenticated dial-in call, and
consider whether you will allow it from an authenticated one. The
goal here is to prevent callers using your modem pool as part of a
chain of logins. This can be hard to detect, particularly if a
hacker sets up a path through several hosts on your site.
At a minimum, don't allow the same modems and phone lines to be used
for both dial-in and dial-out. This can be implemented easily if you
run separate dial-in and dial-out modem pools.
4.5.4.7 Make Your Modem Programming as "Bullet-proof" as Possible
Be sure modems can't be reprogrammed while they're in service. At a
minimum, make sure that three plus signs won't put your dial-in
modems into command mode!
Program your modems to reset to your standard configuration at the
start of each new call. Failing this, make them reset at the end of
each call. This precaution will protect you against accidental
reprogramming of your modems. Resetting at both the end and the
beginning of each call will assure an even higher level of confidence
that a new caller will not inherit a previous caller's session.
Check that your modems terminate calls cleanly. When a user logs out
from an access server, verify that the server hangs up the phone line
properly. It is equally important that the server forces logouts
from whatever sessions were active if the user hangs up unexpectedly.
4.6 Auditing
This section covers the procedures for collecting data generated by
network activity, which may be useful in analyzing the security of a
network and responding to security incidents.
4.6.1 What to Collect
Audit data should include any attempt to achieve a different security
level by any person, process, or other entity in the network. This
includes login and logout, super user access (or the non-UNIX
equivalent), ticket generation (for Kerberos, for example), and any
other change of access or status. It is especially important to note
"anonymous" or "guest" access to public servers.
The actual data to collect will differ for different sites and for
different types of access changes within a site. In general, the
information you want to collect includes: username and hostname, for
login and logout; previous and new access rights, for a change of
access rights; and a timestamp. Of course, there is much more
information which might be gathered, depending on what the system
makes available and how much space is available to store that
information.
One very important note: do not gather passwords. This creates an
enormous potential security breach if the audit records should be
improperly accessed. Do not gather incorrect passwords either, as
they often differ from valid passwords by only a single character or
transposition.
4.6.2 Collection Process
The collection process should be enacted by the host or resource
being accessed. Depending on the importance of the data and the need
to have it local in instances in which services are being denied,
data could be kept local to the resource until needed or be
transmitted to storage after each event.
There are basically three ways to store audit records: in a
read/write file on a host, on a write-once/read-many device (e.g., a
CD-ROM or a specially configured tape drive), or on a write-only
device (e.g., a line printer). Each method has advantages and
disadvantages.
File system logging is the least resource intensive of the three
methods and the easiest to configure. It allows instant access to
the records for analysis, which may be important if an attack is in
progress. File system logging is also the least reliable method. If
the logging host has been compromised, the file system is usually the
first thing to go; an intruder could easily cover up traces of the
intrusion.
Collecting audit data on a write-once device is slightly more effort
to configure than a simple file, but it has the significant advantage
of greatly increased security because an intruder could not alter the
data showing that an intrusion has occurred. The disadvantage of
this method is the need to maintain a supply of storage media and the
cost of that media. Also, the data may not be instantly available.
Line printer logging is useful in system where permanent and
immediate logs are required. A real time system is an example of
this, where the exact point of a failure or attack must be recorded.
A laser printer, or other device which buffers data (e.g., a print
server), may suffer from lost data if buffers contain the needed data
at a critical instant. The disadvantage of, literally, "paper
trails" is the need to keep the printer fed and the need to scan
records by hand. There is also the issue of where to store the,
potentially, enormous volume of paper which may be generated.
For each of the logging methods described, there is also the issue of
securing the path between the device generating the log and actual
logging device (i.e., the file server, tape/CD-ROM drive, printer).
If that path is compromised, logging can be stopped or spoofed or
both. In an ideal world, the logging device would be directly
attached by a single, simple, point-to-point cable. Since that is
usually impractical, the path should pass through the minimum number
of networks and routers. Even if logs can be blocked, spoofing can
be prevented with cryptographic checksums (it probably isn't
necessary to encrypt the logs because they should not contain
sensitive information in the first place).
4.6.3 Collection Load
Collecting audit data may result in a rapid accumulation of bytes so
storage availability for this information must be considered in
advance. There are a few ways to reduce the required storage space.
First, data can be compressed, using one of many methods. Or, the
required space can be minimized by keeping data for a shorter period
of time with only summaries of that data kept in long-term archives.
One major drawback to the latter method involves incident response.
Often, an incident has been ongoing for some period of time when a
site notices it and begins to investigate. At that point in time,
it's very helpful to have detailed audit logs available. If these are
just summaries, there may not be sufficient detail to fully handle
the incident.
4.6.4 Handling and Preserving Audit Data
Audit data should be some of the most carefully secured data at the
site and in the backups. If an intruder were to gain access to audit
logs, the systems themselves, in addition to the data, would be at
risk.
Audit data may also become key to the investigation, apprehension,
and prosecution of the perpetrator of an incident. For this reason,
it is advisable to seek the advice of legal council when deciding how
audit data should be treated. This should happen before an incident
occurs.
If a data handling plan is not adequately defined prior to an
incident, it may mean that there is no recourse in the aftermath of
an event, and it may create liability resulting from improper
treatment of the data.
4.6.5 Legal Considerations
Due to the content of audit data, there are a number of legal
questions that arise which might need to be addressed by your legal
counsel. If you collect and save audit data, you need to be prepared
for consequences resulting both from its existence and its content.
One area concerns the privacy of individuals. In certain instances,
audit data may contain personal information. Searching through the
data, even for a routine check of the system's security, could
represent an invasion of privacy.
A second area of concern involves knowledge of intrusive behavior
originating from your site. If an organization keeps audit data, is
it responsible for examining it to search for incidents? If a host
in one organization is used as a launching point for an attack
against another organization, can the second organization use the
audit data of the first organization to prove negligence on the part
of that organization?
The above examples are meant to be comprehensive, but should motivate
your organization to consider the legal issues involved with audit
data.
4.7 Securing Backups
The procedure of creating backups is a classic part of operating a
computer system. Within the context of this document, backups are
addressed as part of the overall security plan of a site. There are
several aspects to backups that are important within this context:
(1) Make sure your site is creating backups
(2) Make sure your site is using offsite storage for backups. The
storage site should be carefully selected for both its security
and its availability.
(3) Consider encrypting your backups to provide additional protection
of the information once it is off-site. However, be aware that
you will need a good key management scheme so that you'll be
able to recover data at any point in the future. Also, make
sure you will have access to the necessary decryption programs
at such time in the future as you need to perform the
decryption.
(4) Don't always assume that your backups are good. There have been
many instances of computer security incidents that have gone on
for long periods of time before a site has noticed the incident.
In such cases, backups of the affected systems are also tainted.
(5) Periodically verify the correctness and completeness of your
backups.
5. Security Incident Handling
This chapter of the document will supply guidance to be used before,
during, and after a computer security incident occurs on a host,
network, site, or multi-site environment. The operative philosophy
in the event of a breach of computer security is to react according
to a plan. This is true whether the breach is the result of an
external intruder attack, unintentional damage, a student testing
some new program to exploit a software vulnerability, or a
disgruntled employee. Each of the possible types of events, such as
those just listed, should be addressed in advance by adequate
contingency plans.
Traditional computer security, while quite important in the overall
site security plan, usually pays little attention to how to actually
handle an attack once one occurs. The result is that when an attack
is in progress, many decisions are made in haste and can be damaging
to tracking down the source of the incident, collecting evidence to
be used in prosecution efforts, preparing for the recovery of the
system, and protecting the valuable data contained on the system.
One of the most important, but often overlooked, benefits for
efficient incident handling is an economic one. Having both
technical and managerial personnel respond to an incident requires
considerable resources. If trained to handle incidents efficiently,
less staff time is required when one occurs.
Due to the world-wide network most incidents are not restricted to a
single site. Operating systems vulnerabilities apply (in some cases)
to several millions of systems, and many vulnerabilities are
exploited within the network itself. Therefore, it is vital that all
sites with involved parties be informed as soon as possible.
Another benefit is related to public relations. News about computer
security incidents tends to be damaging to an organization's stature
among current or potential clients. Efficient incident handling
minimizes the potential for negative exposure.
A final benefit of efficient incident handling is related to legal
issues. It is possible that in the near future organizations may be
held responsible because one of their nodes was used to launch a
network attack. In a similar vein, people who develop patches or
workarounds may be sued if the patches or workarounds are
ineffective, resulting in compromise of the systems, or, if the
patches or workarounds themselves damage systems. Knowing about
operating system vulnerabilities and patterns of attacks, and then
taking appropriate measures to counter these potential threats, is
critical to circumventing possible legal problems.
The sections in this chapter provide an outline and starting point
for creating your site's policy for handling security incidents. The
sections are:
(1) Preparing and planning (what are the goals and objectives in
handling an incident).
(2) Notification (who should be contacted in the case of an
incident).
- Local managers and personnel
- Law enforcement and investigative agencies
- Computer security incidents handling teams
- Affected and involved sites
- Internal communications
- Public relations and press releases
(3) Identifying an incident (is it an incident and how serious is
it).
(4) Handling (what should be done when an incident occurs).
- Notification (who should be notified about the incident)
- Protecting evidence and activity logs (what records should be
kept from before, during, and after the incident)
- Containment (how can the damage be limited)
- Eradication (how to eliminate the reasons for the incident)
- Recovery (how to reestablish service and systems)
- Follow Up (what actions should be taken after the incident)
(5) Aftermath (what are the implications of past incidents).
(6) Administrative response to incidents.
The remainder of this chapter will detail the issues involved in each
of the important topics listed above, and provide some guidance as to
what should be included in a site policy for handling incidents.
5.1 Preparing and Planning for Incident Handling
Part of handling an incident is being prepared to respond to an
incident before the incident occurs in the first place. This
includes establishing a suitable level of protections as explained in
the preceding chapters. Doing this should help your site prevent
incidents as well as limit potential damage resulting from them when
they do occur. Protection also includes preparing incident handling
guidelines as part of a contingency plan for your organization or
site. Having written plans eliminates much of the ambiguity which
occurs during an incident, and will lead to a more appropriate and
thorough set of responses. It is vitally important to test the
proposed plan before an incident occurs through "dry runs". A team
might even consider hiring a tiger team to act in parallel with the
dry run. (Note: a tiger team is a team of specialists that try to
penetrate the security of a system.)
Learning to respond efficiently to an incident is important for a
number of reasons:
(1) Protecting the assets which could be compromised
(2) Protecting resources which could be utilized more
profitably if an incident did not require their services
(3) Complying with (government or other) regulations
(4) Preventing the use of your systems in attacks against other
systems (which could cause you to incur legal liability)
(5) Minimizing the potential for negative exposure
As in any set of pre-planned procedures, attention must be paid to a
set of goals for handling an incident. These goals will be
prioritized differently depending on the site. A specific set of
objectives can be identified for dealing with incidents:
(1) Figure out how it happened.
(2) Find out how to avoid further exploitation of the same
vulnerability.
(3) Avoid escalation and further incidents.
(4) Assess the impact and damage of the incident.
(5) Recover from the incident.
(6) Update policies and procedures as needed.
(7) Find out who did it (if appropriate and possible).
Due to the nature of the incident, there might be a conflict between
analyzing the original source of a problem and restoring systems and