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