about rumored security problems.
To join the CERT-ADVISORY mailing list, send a message to
CERT@CERT.SEI.CMU.EDU and ask to be added to the mailing
list. The material sent to this list also appears in the
USENET newsgroup "comp.security.announce". Past advisories
are available for anonymous FTP from the host
CERT.SEI.CMU.EDU. The 24-hour hotline number is (412) 268-
7090.
The CERT/CC also maintains a CERT-TOOLS list to encourage
the exchange of information on tools and techniques that
increase the secure operation of Internet systems. The
CERT/CC does not review or endorse the tools described on
the list. To subscribe, send a message to CERT-TOOLS-
REQUEST@CERT.SEI.CMU.EDU and ask to be added to the mailing
list.
The CERT/CC maintains other generally useful security
information for anonymous FTP from CERT.SEI.CMU.EDU. Get
the README file for a list of what is available.
For more information, contact:
CERT
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
(412) 268-7090
cert@cert.sei.cmu.edu.
3.9.7.3.2 DDN Security Coordination Center
For DDN users, the Security Coordination Center (SCC) serves
a function similar to CERT. The SCC is the DDN's clearing-
house for host/user security problems and fixes, and works
with the DDN Network Security Officer. The SCC also
distributes the DDN Security Bulletin, which communicates
information on network and host security exposures, fixes,
and concerns to security and management personnel at DDN
facilities. It is available online, via kermit or anonymous
FTP, from the host NIC.DDN.MIL, in SCC:DDN-SECURITY-yy-
nn.TXT (where "yy" is the year and "nn" is the bulletin
number). The SCC provides immediate assistance with DDN-
related host security problems; call (800) 235-3155 (6:00
a.m. to 5:00 p.m. Pacific Time) or send email to
SCC@NIC.DDN.MIL. For 24 hour coverage, call the MILNET
Trouble Desk (800) 451-7413 or AUTOVON 231-1713.
3.9.7.3.3 NIST Computer Security Resource and Response Center
The National Institute of Standards and Technology (NIST)
has responsibility within the U.S. Federal Government for
computer science and technology activities. NIST has played
a strong role in organizing the CERT System and is now
serving as the CERT System Secretariat. NIST also operates
a Computer Security Resource and Response Center (CSRC) to
provide help and information regarding computer security
events and incidents, as well as to raise awareness about
computer security vulnerabilities.
The CSRC team operates a 24-hour hotline, at (301) 975-5200.
For individuals with access to the Internet, on-line
publications and computer security information can be
obtained via anonymous FTP from the host CSRC.NCSL.NIST.GOV
(129.6.48.87). NIST also operates a personal computer
bulletin board that contains information regarding computer
viruses as well as other aspects of computer security. To
access this board, set your modem to 300/1200/2400 BPS, 1
stop bit, no parity, and 8-bit characters, and call (301)
948-5717. All users are given full access to the board
immediately upon registering.
NIST has produced several special publications related to
computer security and computer viruses in particular; some
of these publications are downloadable. For further
information, contact NIST at the following address:
Computer Security Resource and Response Center
A-216 Technology
Gaithersburg, MD 20899
Telephone: (301) 975-3359
Electronic Mail: CSRC@nist.gov
3.9.7.3.4 DOE Computer Incident Advisory Capability (CIAC)
CIAC is the Department of Energy's (DOE's) Computer Incident
Advisory Capability. CIAC is a four-person team of computer
scientists from Lawrence Livermore National Laboratory
(LLNL) charged with the primary responsibility of assisting
DOE sites faced with computer security incidents (e.g.,
intruder attacks, virus infections, worm attacks, etc.).
This capability is available to DOE sites on a 24-hour-a-day
basis.
CIAC was formed to provide a centralized response capability
(including technical assistance), to keep sites informed of
current events, to deal proactively with computer security
issues, and to maintain liaisons with other response teams
and agencies. CIAC's charter is to assist sites (through
direct technical assistance, providing information, or
referring inquiries to other technical experts), serve as a
clearinghouse for information about threats/known
incidents/vulnerabilities, develop guidelines for incident
handling, develop software for responding to
events/incidents, analyze events and trends, conduct
training and awareness activities, and alert and advise
sites about vulnerabilities and potential attacks.
CIAC's business hours phone number is (415) 422-8193 or FTS
532-8193. CIAC's e-mail address is CIAC@TIGER.LLNL.GOV.
3.9.7.3.5 NASA Ames Computer Network Security Response Team
The Computer Network Security Response Team (CNSRT) is NASA
Ames Research Center's local version of the DARPA CERT.
Formed in August of 1989, the team has a constituency that
is primarily Ames users, but it is also involved in
assisting other NASA Centers and federal agencies. CNSRT
maintains liaisons with the DOE's CIAC team and the DARPA
CERT. It is also a charter member of the CERT System. The
team may be reached by 24 hour pager at (415) 694-0571, or
by electronic mail to CNSRT@AMES.ARC.NASA.GOV.
3.9.7.4 DDN Management Bulletins
The DDN Management Bulletin is distributed electronically by
the DDN NIC under contract to the Defense Communications Agency
(DCA). It is a means of communicating official policy,
procedures, and other information of concern to management
personnel at DDN facilities.
The DDN Security Bulletin is distributed electronically by the
DDN SCC, also under contract to DCA, as a means of
communicating information on network and host security
exposures, fixes, and concerns to security and management
personnel at DDN facilities.
Anyone may join the mailing lists for these two bulletins by
sending a message to NIC@NIC.DDN.MIL and asking to be placed on
the mailing lists. These messages are also posted to the
USENET newsgroup "ddn.mgt-bulletin". For additional
information, see section 8.7.
3.9.7.5 System Administration List
The SYSADM-LIST is a list pertaining exclusively to UNIX system
administration. Mail requests to be added to the list to
SYSADM-LIST-REQUEST@SYSADMIN.COM.
3.9.7.6 Vendor Specific System Lists
The SUN-SPOTS and SUN-MANAGERS lists are discussion groups for
users and administrators of systems supplied by Sun
Microsystems. SUN-SPOTS is a fairly general list, discussing
everything from hardware configurations to simple UNIX
questions. To subscribe, send a message to SUN-SPOTS-
REQUEST@RICE.EDU. This list is also available in the USENET
newsgroup "comp.sys.sun". SUN-MANAGERS is a discussion list
for Sun system administrators and covers all aspects of Sun
system administration. To subscribe, send a message to SUN-
MANAGERS-REQUEST@EECS.NWU.EDU.
The APOLLO list discusses the HP/Apollo system and its
software. To subscribe, send a message to APOLLO-
REQUEST@UMIX.CC.UMICH.EDU. APOLLO-L is a similar list which
can be subscribed to by sending
SUB APOLLO-L your full name
to LISTSERV%UMRVMB.BITNET@VM1.NODAK.EDU.
HPMINI-L pertains to the Hewlett-Packard 9000 series and HP/UX
operating system. To subscribe, send
SUB HPMINI-L your full name
to LISTSERV%UAFSYSB.BITNET@VM1.NODAK.EDU.
INFO-IBMPC discusses IBM PCs and compatibles, as well as MS-
DOS. To subscribe, send a note to INFO-IBMPC-REQUEST@WSMR-
SIMTEL20.ARMY.MIL.
There are numerous other mailing lists for nearly every popular
computer or workstation in use today. For a complete list,
obtain the file "netinfo/interest-groups" via anonymous FTP
from the host FTP.NISC.SRI.COM.
3.9.7.7 Professional Societies and Journals
The IEEE Technical Committee on Security & Privacy publishes a
quarterly magazine, "CIPHER".
IEEE Computer Society,
1730 Massachusetts Ave. N.W.
Washington, DC 2036-1903
The ACM SigSAC (Special Interest Group on Security, Audit, and
Controls) publishes a quarterly magazine, "SIGSAC Review".
Association for Computing Machinery
11 West 42nd St.
New York, N.Y. 10036
The Information Systems Security Association publishes a
quarterly magazine called "ISSA Access".
Information Systems Security Association
P.O. Box 9457
Newport Beach, CA 92658
"Computers and Security" is an "international journal for the
professional involved with computer security, audit and
control, and data integrity."
$266/year, 8 issues (1990)
Elsevier Advanced Technology
Journal Information Center
655 Avenue of the Americas
New York, NY 10010
The "Data Security Letter" is published "to help data security
professionals by providing inside information and knowledgable
analysis of developments in computer and communications
security."
$690/year, 9 issues (1990)
Data Security Letter
P.O. Box 1593
Palo Alto, CA 94302
3.9.8 Problem Reporting Tools
3.9.8.1 Auditing
Auditing is an important tool that can be used to enhance the
security of your installation. Not only does it give you a
means of identifying who has accessed your system (and may have
done something to it) but it also gives you an indication of
how your system is being used (or abused) by authorized users
and attackers alike. In addition, the audit trail
traditionally kept by computer systems can become an invaluable
piece of evidence should your system be penetrated.
3.9.8.1.1 Verify Security
An audit trail shows how the system is being used from day
to day. Depending upon how your site audit log is
configured, your log files should show a range of access
attempts that can show what normal system usage should look
like. Deviation from that normal usage could be the result
of penetration from an outside source using an old or stale
user account. Observing a deviation in logins, for example,
could be your first indication that something unusual is
happening.
3.9.8.1.2 Verify Software Configurations
One of the ruses used by attackers to gain access to a
system is by the insertion of a so-called Trojan Horse
program. A Trojan Horse program can be a program that does
something useful, or merely something interesting. It
always does something unexpected, like steal passwords or
copy files without your knowledge [25]. Imagine a Trojan
login program that prompts for username and password in the
usual way, but also writes that information to a special
file that the attacker can come back and read at will.
Imagine a Trojan Editor program that, despite the file
permissions you have given your files, makes copies of
everything in your directory space without you knowing about
it.
This points out the need for configuration management of the
software that runs on a system, not as it is being
developed, but as it is in actual operation. Techniques for
doing this range from checking each command every time it is
executed against some criterion (such as a cryptoseal,
described above) or merely checking the date and time stamp
of the executable. Another technique might be to check each
command in batch mode at midnight.
3.9.8.2 Tools
COPS is a security tool for system administrators that checks
for numerous common security problems on UNIX systems [27].
COPS is a collection of shell scripts and C programs that can
easily be run on almost any UNIX variant. Among other things,
it checks the following items and sends the results to the
system administrator:
- Checks "/dev/kmem" and other devices for world
read/writability.
- Checks special or important files and directories for
"bad" modes (world writable, etc.).
- Checks for easily-guessed passwords.
- Checks for duplicate user ids, invalid fields in the
password file, etc..
- Checks for duplicate group ids, invalid fields in the
group file, etc..
- Checks all users' home directories and their ".cshrc",
".login", ".profile", and ".rhosts" files for security
problems.
- Checks all commands in the "/etc/rc" files and "cron"
files for world writability.
- Checks for bad "root" paths, NFS file systems exported
to the world, etc..
- Includes an expert system that checks to see if a given
user (usually "root") can be compromised, given that
certain rules are true.
- Checks for changes in the setuid status of programs on the
system.
The COPS package is available from the "comp.sources.unix"
archive on "ftp.uu.net", and also from the UNIX-SW repository
on the MILNET host "wsmr-simtel20.army.mil".
3.9.9 Communication Among Administrators
3.9.9.1 Secure Operating Systems
The following list of products and vendors is adapted from the
National Computer Security Center's (NCSC) Evaluated Products
List. They represent those companies who have either received
an evaluation from the NCSC or are in the process of a product
evaluation. This list is not complete, but it is
representative of those operating systems and add on components
available in the commercial marketplace.
For a more detailed listing of the current products appearing
in the NCSC EPL, contact the NCSC at:
National Computer Security Center
9800 Savage Road
Fort George G. Meade, MD 20755-6000
(301) 859-4458
Version Evaluation
Evaluated Product Vendor Evaluated Class
-----------------------------------------------------------------------
Secure Communications Honeywell Information 2.1 A1
Processor (SCOMP) Systems, Inc.
Multics Honeywell Information MR11.0 B2
Systems, Inc.
System V/MLS 1.1.2 on UNIX AT&T 1.1.2 B1
System V 3.1.1 on AT&T 3B2/500and 3B2/600
OS 1100 Unisys Corp. Security B1
Release 1
MPE V/E Hewlett-Packard Computer G.03.04 C2
Systems Division
AOS/VS on MV/ECLIPSE series Data General Corp. 7.60 C2
VM/SP or VM/SP HPO with CMS, IBM Corp. 5 C2
RACF, DIRMAINT, VMTAPE-MS,
ISPF
MVS/XA with RACF IBM Corp. 2.2,2.3 C2
AX/VMS Digital Equipment Corp. 4.3 C2
NOS Control Data Corp. NOS
Security C2
Eval Product
TOP SECRET CGA Software Products 3.0/163 C2
Group, Inc.
Access Control Facility 2 SKK, Inc. 3.1.3 C2
UTX/32S Gould, Inc. Computer 1.0 C2
Systems Division
A Series MCP/AS with Unisys Corp. 3.7 C2
InfoGuard Security
Enhancements
Primos Prime Computer, Inc. 21.0.1DODC2A C2
Resource Access Control IBM Corp. 1.5 C1
Facility (RACF)
Version Candidate
Candidate Product Vendor Evaluated Class
-----------------------------------------------------------------------
Boeing MLS LAN Boeing Aerospace A1 M1
Trusted XENIX Trusted Information
Systems, Inc. B2
VSLAN VERDIX Corp. B2
System V/MLS AT&T B1
VM/SP with RACF IBM Corp. 5/1.8.2 C2
Wang SVS/OS with CAP Wang Laboratories, Inc. 1.0 C2
3.9.9.2 Obtaining Fixes for Known Problems
It goes without saying that computer systems have bugs. Even
operating systems, upon which we depend for protection of our
data, have bugs. And since there are bugs, things can be
broken, both maliciously and accidentally. It is important
that whenever bugs are discovered, a should fix be identified
and implemented as soon as possible. This should minimize any
exposure caused by the bug in the first place.
A corollary to the bug problem is: from whom do I obtain the
fixes? Most systems have some support from the manufacturer or
supplier. Fixes coming from that source tend to be implemented
quickly after receipt. Fixes for some problems are often
posted on the network and are left to the system administrators
to incorporate as they can. The problem is that one wants to
have faith that the fix will close the hole and not introduce
any others. We will tend to trust that the manufacturer's
fixes are better than those that are posted on the net.
3.9.9.3 Sun Customer Warning System
Sun Microsystems has established a Customer Warning System
(CWS) for handling security incidents. This is a formal
process which includes:
- Having a well advertised point of contact in Sun
for reporting security problems.
- Pro-actively alerting customers of worms, viruses,
or other security holes that could affect their systems.
- Distributing the patch (or work-around) as quickly
as possible.
They have created an electronic mail address, SECURITY-
ALERT@SUN.COM, which will enable customers to report security
problems. A voice-mail backup is available at (415) 688-9081.
A "Security Contact" can be designated by each customer site;
this person will be contacted by Sun in case of any new
security problems. For more information, contact your Sun
representative.
3.9.9.4 Trusted Archive Servers
Several sites on the Internet maintain large repositories of
public-domain and freely distributable software, and make this
material available for anonymous FTP. This section describes
some of the larger repositories. Note that none of these
servers implements secure checksums or anything else
guaranteeing the integrity of their data. Thus, the notion of
"trust" should be taken as a somewhat limited definition.
3.9.9.4.1 Sun Fixes on UUNET
Sun Microsystems has contracted with UUNET Communications
Services, Inc., to make fixes for bugs in Sun software
available via anonymous FTP. You can access these fixes by
using the "ftp" command to connect to the host FTP.UU.NET.
Then change into the directory "sun-dist/security", and
obtain a directory listing. The file "README" contains a
brief description of what each file in this directory
contains, and what is required to install the fix.
3.9.9.4.2 Berkeley Fixes
The University of California at Berkeley also makes fixes
available via anonymous FTP; these fixes pertain primarily
to the current release of BSD UNIX (currently, release 4.3).
However, even if you are not running their software, these
fixes are still important, since many vendors (Sun, DEC,
Sequent, etc.) base their software on the Berkeley releases.
The Berkeley fixes are available for anonymous FTP from the
host UCBARPA.BERKELEY.EDU in the directory "4.3/ucb-fixes".
The file "INDEX" in this directory describes what each file
contains. They are also available from UUNET (see section
3.9.9.4.3).
Berkeley also distributes new versions of "sendmail" and
"named" from this machine. New versions of these commands
are stored in the "4.3" directory, usually in the files
"sendmail.tar.Z" and "bind.tar.Z", respectively.
3.9.9.4.3 Simtel-20 and UUNET
The two largest general-purpose software repositories on the
Internet are the hosts WSMR-SIMTEL20.ARMY.MIL and
FTP.UU.NET.
WSMR-SIMTEL20.ARMY.MIL is a TOPS-20 machine operated by the
U.S. Army at White Sands Missile Range (WSMR), New Mexico.
The directory "pd2:<unix-c>" contains a large amount of UNIX
software, primarily taken from the "comp.sources"
newsgroups. The directories "pd1:<msdos>" and
"pd2:<msdos2>" contains software for IBM PC systems, and
"pd3:<macintosh>" contains software for the Apple Macintosh.
FTP.UU.NET is operated by UUNET Communications Services,
Inc. in Falls Church, Virginia. This company sells Internet
and USENET access to sites all over the country (and
internationally). The software posted to the following
USENET source newsgroups is stored here, in directories of
the same name:
comp.sources.games
comp.sources.misc
comp.sources.sun
comp.sources.unix
comp.sources.x
Numerous other distributions, such as all the freely
distributable Berkeley UNIX source code, Internet Request
for Comments (RFCs), and so on are also stored on this
system.
3.9.9.4.4 Vendors
Many vendors make fixes for bugs in their software available
electronically, either via mailing lists or via anonymous
FTP. You should contact your vendor to find out if they
offer this service, and if so, how to access it. Some
vendors that offer these services include Sun Microsystems
(see above), Digital Equipment Corporation (DEC), the
University of California at Berkeley (see above), and Apple
Computer [5, CURRY].
4. Types of Security Procedures
4.1 System Security Audits
Most businesses undergo some sort of annual financial auditing as a
regular part of their business life. Security audits are an
important part of running any computing environment. Part of the
security audit should be a review of any policies that concern system
security, as well as the mechanisms that are put in place to enforce
them.
4.1.1 Organize Scheduled Drills
Although not something that would be done each day or week,
scheduled drills may be conducted to determine if the procedures
defined are adequate for the threat to be countered. If your
major threat is one of natural disaster, then a drill would be
conducted to verify your backup and recovery mechanisms. On the
other hand, if your greatest threat is from external intruders
attempting to penetrate your system, a drill might be conducted to
actually try a penetration to observe the effect of the policies.
Drills are a valuable way to test that your policies and
procedures are effective. On the other hand, drills can be time-
consuming and disruptive to normal operations. It is important to
weigh the benefits of the drills against the possible time loss
which may be associated with them.
4.1.2 Test Procedures
If the choice is made to not to use scheduled drills to examine
your entire security procedure at one time, it is important to
test individual procedures frequently. Examine your backup
procedure to make sure you can recover data from the tapes. Check
log files to be sure that information which is supposed to be
logged to them is being logged to them, etc..
When a security audit is mandated, great care should be used in
devising tests of the security policy. It is important to clearly
identify what is being tested, how the test will be conducted, and
results expected from the test. This should all be documented and
included in or as an adjunct to the security policy document
itself.
It is important to test all aspects of the security policy, both
procedural and automated, with a particular emphasis on the
automated mechanisms used to enforce the policy. Tests should be
defined to ensure a comprehensive examination of policy features,
that is, if a test is defined to examine the user logon process,
it should be explicitly stated that both valid and invalid user
names and passwords will be used to demonstrate proper operation
of the logon program.
Keep in mind that there is a limit to the reasonableness of tests.
The purpose of testing is to ensure confidence that the security
policy is being correctly enforced, and not to "prove" the
absoluteness of the system or policy. The goal should be to
obtain some assurance that the reasonable and credible controls
imposed by your security policy are adequate.
4.2 Account Management Procedures
Procedures to manage accounts are important in preventing
unauthorized access to your system. It is necessary to decide
several things: Who may have an account on the system? How long may
someone have an account without renewing his or her request? How do
old accounts get removed from the system? The answers to all these
questions should be explicitly set out in the policy.
In addition to deciding who may use a system, it may be important to
determine what each user may use the system for (is personal use
allowed, for example). If you are connected to an outside network,
your site or the network management may have rules about what the
network may be used for. Therefore, it is important for any security
policy to define an adequate account management procedure for both
administrators and users. Typically, the system administrator would
be responsible for creating and deleting user accounts and generally
maintaining overall control of system use. To some degree, account
management is also the responsibility of each system user in the
sense that the user should observe any system messages and events
that may be indicative of a policy violation. For example, a message
at logon that indicates the date and time of the last logon should be
reported by the user if it indicates an unreasonable time of last
logon.
4.3 Password Management Procedures
A policy on password management may be important if your site wishes
to enforce secure passwords. These procedures may range from asking
or forcing users to change their passwords occasionally to actively
attempting to break users' passwords and then informing the user of
how easy it was to do. Another part of password management policy
covers who may distribute passwords - can users give their passwords
to other users?
Section 2.3 discusses some of the policy issues that need to be
decided for proper password management. Regardless of the policies,
password management procedures need to be carefully setup to avoid
disclosing passwords. The choice of initial passwords for accounts
is critical. In some cases, users may never login to activate an
account; thus, the choice of the initial password should not be
easily guessed. Default passwords should never be assigned to
accounts: always create new passwords for each user. If there are
any printed lists of passwords, these should be kept off-line in
secure locations; better yet, don't list passwords.
4.3.1 Password Selection
Perhaps the most vulnerable part of any computer system is the
account password. Any computer system, no matter how secure it is
from network or dial-up attack, Trojan horse programs, and so on,
can be fully exploited by an intruder if he or she can gain access
via a poorly chosen password. It is important to define a good
set of rules for password selection, and distribute these rules to
all users. If possible, the software which sets user passwords
should be modified to enforce as many of the rules as possible.
A sample set of guidelines for password selection is shown below:
- DON'T use your login name in any form (as-is,
reversed, capitalized, doubled, etc.).
- DON'T use your first, middle, or last name in any form.
- DON'T use your spouse's or child's name.
- DON'T use other information easily obtained about you.
This includes license plate numbers, telephone numbers,
social security numbers, the make of your automobile,
the name of the street you live on, etc..
- DON'T use a password of all digits, or all the same
letter.
- DON'T use a word contained in English or foreign
language dictionaries, spelling lists, or other
lists of words.
- DON'T use a password shorter than six characters.
- DO use a password with mixed-case alphabetics.
- DO use a password with non-alphabetic characters (digits
or punctuation).
- DO use a password that is easy to remember, so you don't
have to write it down.
- DO use a password that you can type quickly, without
having to look at the keyboard.
Methods of selecting a password which adheres to these guidelines
include:
- Choose a line or two from a song or poem, and use the
first letter of each word.
- Alternate between one consonant and one or two vowels, up
to seven or eight characters. This provides nonsense
words which are usually pronounceable, and thus easily
remembered.
- Choose two short words and concatenate them together with
a punctuation character between them.
Users should also be told to change their password periodically,
usually every three to six months. This makes sure that an
intruder who has guessed a password will eventually lose access,
as well as invalidating any list of passwords he/she may have
obtained. Many systems enable the system administrator to force
users to change their passwords after an expiration period; this
software should be enabled if your system supports it [5, CURRY].
Some systems provide software which forces users to change their
passwords on a regular basis. Many of these systems also include
password generators which provide the user with a set of passwords
to choose from. The user is not permitted to make up his or her
own password. There are arguments both for and against systems
such as these. On the one hand, by using generated passwords,
users are prevented from selecting insecure passwords. On the
other hand, unless the generator is good at making up easy to
remember passwords, users will begin writing them down in order to
remember them.
4.3.2 Procedures for Changing Passwords
How password changes are handled is important to keeping passwords
secure. Ideally, users should be able to change their own
passwords on-line. (Note that password changing programs are a
favorite target of intruders. See section 4.4 on configuration
management for further information.)
However, there are exception cases which must be handled
carefully. Users may forget passwords and not be able to get onto
the system. The standard procedure is to assign the user a new
password. Care should be taken to make sure that the real person
is requesting the change and gets the new password. One common
trick used by intruders is to call or message to a system
administrator and request a new password. Some external form of
verification should be used before the password is assigned. At
some sites, users are required to show up in person with ID.
There may also be times when many passwords need to be changed.
If a system is compromised by an intruder, the intruder may be
able to steal a password file and take it off the system. Under
these circumstances, one course of action is to change all
passwords on the system. Your site should have procedures for how
this can be done quickly and efficiently. What course you choose
may depend on the urgency of the problem. In the case of a known
attack with damage, you may choose to forcibly disable all
accounts and assign users new passwords before they come back onto
the system. In some places, users are sent a message telling them
that they should change their passwords, perhaps within a certain
time period. If the password isn't changed before the time period
expires, the account is locked.
Users should be aware of what the standard procedure is for
passwords when a security event has occurred. One well-known
spoof reported by the Computer Emergency Response Team (CERT)
involved messages sent to users, supposedly from local system
administrators, requesting them to immediately change their
password to a new value provided in the message [24]. These
messages were not from the administrators, but from intruders
trying to steal accounts. Users should be warned to immediately
report any suspicious requests such as this to site
administrators.
4.4 Configuration Management Procedures
Configuration management is generally applied to the software
development process. However, it is certainly applicable in a
operational sense as well. Consider that the since many of the
system level programs are intended to enforce the security policy, it
is important that these be "known" as correct. That is, one should
not allow system level programs (such as the operating system, etc.)
to be changed arbitrarily. At very least, the procedures should
state who is authorized to make changes to systems, under what
circumstances, and how the changes should be documented.
In some environments, configuration management is also desirable as
applied to physical configuration of equipment. Maintaining valid
and authorized hardware configuration should be given due
consideration in your security policy.
4.4.1 Non-Standard Configurations
Occasionally, it may be beneficial to have a slightly non-standard
configuration in order to thwart the "standard" attacks used by
some intruders. The non-standard parts of the configuration might
include different password encryption algorithms, different
configuration file locations, and rewritten or functionally
limited system commands.
Non-standard configurations, however, also have their drawbacks.
By changing the "standard" system, these modifications make
software maintenance more difficult by requiring extra
documentation to be written, software modification after operating
system upgrades, and, usually, someone with special knowledge of
the changes.
Because of the drawbacks of non-standard configurations, they are
often only used in environments with a "firewall" machine (see
section 3.9.1). The firewall machine is modified in non-standard
ways since it is susceptible to attack, while internal systems
behind the firewall are left in their standard configurations.
5. Incident Handling
5.1 Overview
This section of the document will supply some guidance to be applied
when a computer security event is in progress on a machine, network,
site, or multi-site environment. The operative philosophy in the
event of a breach of computer security, whether it be an external
intruder attack or a disgruntled employee, is to plan for adverse
events in advance. There is no substitute for creating contingency
plans for the types of events described above.
Traditional computer security, while quite important in the overall
site security plan, usually falls heavily on protecting systems from
attack, and perhaps monitoring systems to detect attacks. Little
attention is usually paid for how to actually handle the attack when
it 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.
5.1.1 Have a Plan to Follow in Case of an Incident
Part of handling an incident is being prepared to respond before
the incident occurs. This includes establishing a suitable level
of protections, so that if the incident becomes severe, the damage
which can occur is limited. Protection includes preparing
incident handling guidelines or a contingency response 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. Second, part of
protection is preparing a method of notification, so you will know
who to call and the relevant phone numbers. It is important, for
example, to conduct "dry runs," in which your computer security
personnel, system administrators, and managers simulate handling
an incident.
Learning to respond efficiently to an incident is important for
numerous reasons. The most important benefit is directly to human
beings--preventing loss of human life. Some computing systems are
life critical systems, systems on which human life depends (e.g.,
by controlling some aspect of life-support in a hospital or
assisting air traffic controllers).
An important but often overlooked benefit is an economic one.
Having both technical and managerial personnel respond to an
incident requires considerable resources, resources which could be
utilized more profitably if an incident did not require their
services. If these personnel are trained to handle an incident
efficiently, less of their time is required to deal with that
incident.
A third benefit is protecting classified, sensitive, or
proprietary information. One of the major dangers of a computer
security incident is that information may be irrecoverable.
Efficient incident handling minimizes this danger. When
classified information is involved, other government regulations
may apply and must be integrated into any plan for incident
handling.
A fourth 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 sued 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 damage to systems, or if the patches or
workarounds themselves damage systems. Knowing about operating
system vulnerabilities and patterns of attacks and then taking
appropriate measures is critical to circumventing possible legal
problems.
5.1.2 Order of Discussion in this Session Suggests an Order for
a Plan
This chapter is arranged such that a list may be generated from
the Table of Contents to provide a starting point for creating a
policy for handling ongoing incidents. The main points to be
included in a policy for handling incidents are:
o Overview (what are the goals and objectives in handling the
incident).
o Evaluation (how serious is the incident).
o Notification (who should be notified about the incident).
o Response (what should the response to the incident be).
o Legal/Investigative (what are the legal and prosecutorial
implications of the incident).
o Documentation Logs (what records should be kept from before,
during, and after the incident).
Each of these points is important in an overall plan for handling
incidents. The remainder of this chapter will detail the issues
involved in each of these topics, and provide some guidance as to
what should be included in a site policy for handling incidents.
5.1.3 Possible Goals and Incentives for Efficient Incident
Handling
As in any set of pre-planned procedures, attention must be placed
on a set of goals to be obtained in handling an incident. These
goals will be placed in order of importance depending on the site,
but one such set of goals might be:
Assure integrity of (life) critical systems.
Maintain and restore data.
Maintain and restore service.
Figure out how it happened.
Avoid escalation and further incidents.
Avoid negative publicity.
Find out who did it.
Punish the attackers.
It is important to prioritize actions to be taken during an
incident well in advance of the time an incident occurs.
Sometimes an incident may be so complex that it is impossible to
do everything at once to respond to it; priorities are essential.
Although priorities will vary from institution-to-institution, the
following suggested priorities serve as a starting point for
defining an organization's response:
o Priority one -- protect human life and people's
safety; human life always has precedence over all
other considerations.
o Priority two -- protect classified and/or sensitive
data (as regulated by your site or by government
regulations).
o Priority three -- protect other data, including
proprietary, scientific, managerial and other data,
because loss of data is costly in terms of resources.
o Priority four -- prevent damage to systems (e.g., loss
or alteration of system files, damage to disk drives,
etc.); damage to systems can result in costly down
time and recovery.
o Priority five -- minimize disruption of computing
resources; it is better in many cases to shut a system
down or disconnect from a network than to risk damage
to data or systems.
An important implication for defining priorities is that once
human life and national security considerations have been
addressed, it is generally more important to save data than system
software and hardware. Although it is undesirable to have any
damage or loss during an incident, systems can be replaced; the
loss or compromise of data (especially classified data), however,
is usually not an acceptable outcome under any circumstances.
Part of handling an incident is being prepared to respond before
the incident occurs. This includes establishing a suitable level
of protections so that if the incident becomes severe, the damage
which can occur is limited. Protection includes preparing
incident handling guidelines or a contingency response plan for
your organization or site. Written plans eliminate much of the
ambiguity which occurs during an incident, and will lead to a more
appropriate and thorough set of responses. Second, part of
protection is preparing a method of notification so you will know
who to call and how to contact them. For example, every member of
the Department of Energy's CIAC Team carries a card with every
other team member's work and home phone numbers, as well as pager
numbers. Third, your organization or site should establish backup
procedures for every machine and system. Having backups
eliminates much of the threat of even a severe incident, since
backups preclude serious data loss. Fourth, you should set up
secure systems. This involves eliminating vulnerabilities,
establishing an effective password policy, and other procedures,
all of which will be explained later in this document. Finally,
conducting training activities is part of protection. It is
important, for example, to conduct "dry runs," in which your
computer security personnel, system administrators, and managers
simulate handling an incident.
5.1.4 Local Policies and Regulations Providing Guidance
Any plan for responding to security incidents should be guided by
local policies and regulations. Government and private sites that
deal with classified material have specific rules that they must
follow.
The policies your site makes about how it responds to incidents
(as discussed in sections 2.4 and 2.5) will shape your response.
For example, it may make little sense to create mechanisms to
monitor and trace intruders if your site does not plan to take
action against the intruders if they are caught. Other
organizations may have policies that affect your plans. Telephone
companies often release information about telephone traces only to
law enforcement agencies.
Section 5.5 also notes that if any legal action is planned, there
are specific guidelines that must be followed to make sure that
any information collected can be used as evidence.
5.2 Evaluation
5.2.1 Is It Real?
This stage involves determining the exact problem. Of course
many, if not most, signs often associated with virus infections,
system intrusions, etc., are simply anomalies such as hardware
failures. To assist in identifying whether there really is an
incident, it is usually helpful to obtain and use any detection
software which may be available. For example, widely available
software packages can greatly assist someone who thinks there may
be a virus in a Macintosh computer. Audit information is also
extremely useful, especially in determining whether there is a
network attack. It is extremely important to obtain a system
snapshot as soon as one suspects that something is wrong. Many
incidents cause a dynamic chain of events to occur, and an initial
system snapshot may do more good in identifying the problem and
any source of attack than most other actions which can be taken at
this stage. Finally, it is important to start a log book.
Recording system events, telephone conversations, time stamps,
etc., can lead to a more rapid and systematic identification of
the problem, and is the basis for subsequent stages of incident
handling.
There are certain indications or "symptoms" of an incident which
deserve special attention:
o System crashes.
o New user accounts (e.g., the account RUMPLESTILTSKIN
has unexplainedly been created), or high activity on
an account that has had virtually no activity for
months.
o New files (usually with novel or strange file names,
such as data.xx or k).
o Accounting discrepancies (e.g., in a UNIX system you
might notice that the accounting file called
/usr/admin/lastlog has shrunk, something that should
make you very suspicious that there may be an
intruder).
o Changes in file lengths or dates (e.g., a user should
be suspicious if he/she observes that the .EXE files in
an MS DOS computer have unexplainedly grown
by over 1800 bytes).
o Attempts to write to system (e.g., a system manager
notices that a privileged user in a VMS system is
attempting to alter RIGHTSLIST.DAT).
o Data modification or deletion (e.g., files start to
disappear).
o Denial of service (e.g., a system manager and all
other users become locked out of a UNIX system, which
has been changed to single user mode).
o Unexplained, poor system performance (e.g., system
response time becomes unusually slow).
o Anomalies (e.g., "GOTCHA" is displayed on a display
terminal or there are frequent unexplained "beeps").
o Suspicious probes (e.g., there are numerous
unsuccessful login attempts from another node).
o Suspicious browsing (e.g., someone becomes a root user
on a UNIX system and accesses file after file in one
user's account, then another's).
None of these indications is absolute "proof" that an incident is
occurring, nor are all of these indications normally observed when
an incident occurs. If you observe any of these indications,
however, it is important to suspect that an incident might be
occurring, and act accordingly. There is no formula for
determining with 100 percent accuracy that an incident is
occurring (possible exception: when a virus detection package
indicates that your machine has the nVIR virus and you confirm
this by examining contents of the nVIR resource in your Macintosh
computer, you can be very certain that your machine is infected).
It is best at this point to collaborate with other technical and
computer security personnel to make a decision as a group about
whether an incident is occurring.
5.2.2 Scope
Along with the identification of the incident is the evaluation of
the scope and impact of the problem. It is important to correctly
identify the boundaries of the incident in order to effectively
deal with it. In addition, the impact of an incident will
determine its priority in allocating resources to deal with the
event. Without an indication of the scope and impact of the
event, it is difficult to determine a correct response.
In order to identify the scope and impact, a set of criteria
should be defined which is appropriate to the site and to the type
of connections available. Some of the issues are:
o Is this a multi-site incident?
o Are many computers at your site effected by this
incident?
o Is sensitive information involved?
o What is the entry point of the incident (network,
phone line, local terminal, etc.)?
o Is the press involved?
o What is the potential damage of the incident?