4. Security Services and Procedures

< Day Day Up >

This appendix guides you through a number of topics that should be addressed when securing a site. Each section touches on a security service or capability that may be required to protect the information and systems at a site. The topics are presented at a fairly high level to introduce you to the concepts.

Throughout the appendix, you will find significant mention of cryptography. It is outside the scope of this appendix to delve into details concerning cryptography, but the interested reader can obtain more information from books and articles listed in the reference section.

4.1 Authentication

For many years, the prescribed method for authenticating users has been through the use of standard, reusable passwords. Originally, these passwords were used by users at terminals to authenticate themselves to a central computer. At the time, there were no networks (internally or externally), so the risk of disclosure of the clear-text password was minimal. Today, systems are connected together through local networks, and these local networks are further connected together and to the Internet. Users are logging in from all over the globe; their reusable passwords are often transmitted across those same networks in clear text, ripe for anyone in-between to capture. And indeed, the CERT ^[3] Coordination Center and other response teams are seeing a tremendous number of incidents involving packet sniffers that are capturing the clear-text passwords.

With the advent of newer technologies such as one-time passwords (e.g., S/Key), Pretty Good Privacy (PGP), and token-based authentication devices, people are using password-like strings as secret tokens and pins. If these secret tokens and pins are not properly selected and protected, the authentication will be easily subverted.

4.1.1 One-Time Passwords

As mentioned earlier, given today's networked environments, it is recommended that sites concerned about the security and integrity of their systems and networks consider moving away from standard, reusable passwords. There have been many incidents involving Trojan network programs (e.g., telnet and rlogin) and network packet-sniffing programs. These programs capture clear-text host name/account name/password triplets. Intruders can use the captured information for subsequent access to those hosts and accounts. This is possible because (1) the password is used over and over (hence the term "reusable"), and (2) the password passes across the network in clear text.

Several authentication techniques have been developed that address this problem. Among these techniques are challenge-response technologies that provide passwords that are only used once (commonly called one-time passwords). There are a number of products available that sites should consider using. The decision to use a product is the responsibility of each organization, and each organization should perform its own evaluation and selection.

4.1.2 Kerberos

Kerberos is a distributed network security system that provides for authentication across unsecured networks. If requested by the application, integrity, and encryption can also be provided. Kerberos was originally developed at MIT in the mid-1980s. There are two major releases of Kerberos, version 4 and version 5, which for practical purposes are incompatible.

Kerberos relies on a symmetric key database using a key distribution center (KDC) known as the Kerberos server. A user or service (known as "principals") is granted electronic "tickets" after properly communicating with the KDC. These tickets are used for authentication between principals. All tickets include a time stamp that limits the time period for which the ticket is valid. Therefore, Kerberos clients and servers must have a secure time source and be able to keep time accurately.

The practical side of Kerberos is its integration with the application level. Typical applications such as FTP, telnet, POP, and NFS have been integrated with the Kerberos system. There are a variety of implementations that have varying levels of integration. Please see Kerberos FAQ available at http://www.ov.com/misc/krb-faq.html for the latest information.

4.1.3 Choosing and Protecting Secret Tokens and PINs

When selecting secret tokens, take care to choose them carefully. Like the selection of passwords, they should be robust against brute-force efforts to guess them. That is, they should not be single words in any language, any common industry or cultural acronyms, etc. Ideally, they will be longer rather than shorter and consist of pass phrases that combine upper- and lower-case character, digits, and other characters.

Once chosen, the protection of these secret tokens is very important. Some are used as pins to hardware devices (such as token cards) and these should not be written down or placed in the same location as the device with which they are associated. Others, such as a secret PGP key, should be protected from unauthorized access.

One final word on this subject. When using cryptography products such as PGP, take care to determine the proper key length and ensure that your users are trained to do likewise. As technology advances, the minimum safe key length continues to grow. Make sure your site keeps up with the latest knowledge on the technology so that you can ensure that any cryptography in use is providing the protection you believe it is.

4.1.4 Password Assurance

While the need to eliminate the use of standard, reusable passwords cannot be overstated, it is recognized that some organizations may still be using them. While it is recommended that these organizations transition to the use of better technology, in the meantime we have the following advice to help with the selection and maintenance of traditional passwords. But remember, none of these measures provides protection against disclosure due to sniffer programs.

The importance of robust passwords. In many (if not most) cases of system penetration, the intruder needs to gain access to an account on the system. One way that goal is typically accomplished is through guessing the password of a legitimate user. This is often accomplished by running an automated password cracking program, which utilizes a very large dictionary, against the system's password file. The only way to guard against passwords being disclosed in this manner is through the careful selection of passwords that cannot be easily guessed (i.e., combinations of numbers, letters, and punctuation characters). Passwords should also be as long as the system supports and users can tolerate.
Changing default passwords. Many operating systems and application programs are installed with default accounts and passwords. These must be changed immediately to something that cannot be guessed or cracked.
Restricting access to the password file. In particular, a site wants to protect the encrypted password portion of the file so that would-be intruders do not have them available for cracking. One effective technique is to use shadow passwords, where the password field of the standard file contains a dummy or false password. The file containing the legitimate passwords is protected elsewhere on the system.
Password aging. When and how to expire passwords is still a subject of controversy among the security community. It is generally accepted that a password should not be maintained once an account is no longer in use, but it is hotly debated whether a user should be forced to change a good password that is in active use. The arguments for changing passwords relate to the prevention of the continued use of penetrated accounts. However, the opposition claims that frequent password changes lead to users writing down their passwords in visible areas (such as pasting them to a terminal), or to users selecting very simple passwords that are easy to guess. It should also be stated that an intruder will probably use a captured or guessed password sooner rather than later, in which case password aging provides little if any protection.

While there is no definitive answer to this dilemma, a password policy should directly address the issue and provide guidelines for how often a user should change the password. Certainly, an annual change in password is usually not difficult for most users, and you should consider requiring it. It is recommended that passwords are changed at least whenever a privileged account is compromised, a critical change in personnel (especially if it is an administrator!) occurs, or when an account has been compromised. In addition, if a privileged account password is compromised, all passwords on the system should be changed.
Password/account blocking. Some sites find it useful to disable accounts after a predefined number of failed attempts to authenticate. If your site decides to employ this mechanism, it is recommended that the mechanism does not "advertise" itself. After disabling, even if the correct password is presented, the message displayed should remain that of a failed login attempt. Implementing this mechanism will require that legitimate users contact their system administrator to request that their account be reactivated.
A word about the finger daemon. By default, the finger daemon displays considerable system and user information. For example, it can display a list of all users currently using a system or all the contents of a specific user's plan file. This information can be used by would-be intruders to identify user names and guess their passwords. It is recommended that sites consider modifying finger to restrict the information displayed.

4.2 Confidentiality

There will be information assets that your site will want to protect from disclosure to unauthorized entities. Operating systems often have built-in file protection mechanisms that allow an administrator to control who on the system can access, or "see," the contents of a given file. A more secure way to provide confidentiality is through encryption. Encryption is accomplished by scrambling data so that it is very difficult and time consuming for anyone other than the authorized recipients or owners to obtain the plain text. Authorized recipients and the owner of the information will possess the corresponding decryption keys that allow them to easily unscramble the text to a readable (clear text) form. We recommend that sites use encryption to provide confidentiality and protect valuable information.

The use of encryption is sometimes controlled by governmental and site regulations, so we encourage administrators to become informed of laws or policies that regulate its use before employing it. It is outside the scope of this document to discuss the various algorithms and programs available for this purpose but we do caution against the casual use of the UNIX crypt program, as it has been found to be easily broken. We also encourage everyone to take time to understand the strength of the encryption in any given algorithm/product before using it. Most well-known products are documented in the literature, so this should be a fairly easy task.

4.3 Integrity

As an administrator, you will want to make sure that information (e.g., operating system files, company data, etc.) has not been altered in an unauthorized fashion. This means you will want to provide some assurance as to the integrity of the information on your systems. One way to provide this is to produce a checksum of the unaltered file, store that checksum offline, and periodically check to make sure the checksum of the online file has not changed (which would indicate the data has not been modified).

Some operating systems come with checksumming programs, such as the UNIX sum program. However, these may not provide the protection you actually need. Files can be modified to preserve the result of the UNIX sum program! Therefore, we suggest that you use a cryptographically strong program, such as the message digesting program MD5, to produce the checksums you will be using to assure integrity.

There are other applications where integrity will need to be assured, such as when transmitting an e-mail message between two parties. There are products available that can provide this capability. Once you identify that this is a capability you need, you can go about identifying technologies that will provide it.

4.4 Authorization

Authorization refers to the process of granting privileges to processes and ultimately to users. This differs from authentication in that authentication is the process used to identify a user. Once identified (reliably), the privileges, rights, property, and permissible actions of the user are determined by authorization.

Explicitly listing the authorized activities of each user (and user process) with respect to all resources (objects) is impossible in a reasonable system. In a real system certain techniques are used to simplify the process of granting and checking authorization(s).

One approach, popularized in UNIX systems, is to assign to each object three classes of user: owner, group, and world. The owner is either the creator of the object or the user assigned as owner by the super-user. The owner permissions (read, write, and execute) apply only to the owner. A group is a collection of users that share access rights to an object. The group permissions (read, write, and execute) apply to all users in the group (except the owner). The world refers to everybody else with access to the system. The world permissions (read, write, and execute) apply to all users (except the owner and members of the group).

Another approach is to attach to an object a list that explicitly contains the identity of all permitted users (or groups). This is an Access Control List (ACL). The advantage of ACLs is that they are easily maintained (one central list per object) and it is very easy to visually check who has access to what. The disadvantages are the extra resources required to store such lists, as well as the vast number of such lists required for large systems.

4.5 Access

4.5.1 Physical Access

Restrict physical access to hosts, allowing access only to those people who are supposed to use the hosts. Hosts include "trusted" terminals (i.e., terminals that allow unauthenticated use such as system consoles, operator terminals, and terminals dedicated to special tasks), and individual microcomputers and workstations, especially those connected to your network. Make sure people's work areas mesh well with access restrictions; otherwise they will find ways to circumvent your physical security (e.g., jamming doors open).

Keep original and backup copies of data and programs safe. Apart from keeping them in good condition for backup purposes, they must be protected from theft. It is important to keep backups in a separate location from the originals, not only for damage considerations but also to guard against theft.

Portable hosts are a particular risk. Make sure it will not cause problems if one of your staff's portable computers is stolen. Consider developing guidelines for the kinds of data that should be allowed to reside on the disks of portable computers, as well as how the data should be protected (e.g., encryption) when it is on a portable computer.

Other areas where physical access should be restricted are the wiring closets and important network elements such as file servers, name server hosts, and routers.

4.5.2 Walk-Up Network Connections

By "walk-up" connections, we mean network connection points located to provide a convenient way for users to connect a portable host to your network.

Consider whether you need to provide this service, bearing in mind that it allows any user to attach an unauthorized host to your network. This increases the risk of attacks via techniques such as IP address spoofing, packet sniffing, etc. Users and site management must appreciate the risks involved. If you decide to provide walk-up connections, plan the service carefully and define precisely where you will provide it so that you can ensure the necessary physical access security.

A walk-up host should be authenticated before its user is permitted to access resources on your network. As an alternative, it may be possible to control physical access. For example, if the service is to be used by students, you might only provide walk-up connection sockets in student laboratories.

If you are providing walk-up access for visitors to connect back to their home networks (e.g., to read e-mail, etc.) in your facility, consider using a separate subnet that has no connectivity to the internal network.

Keep an eye on any area that contains unmonitored access to the network, such as vacant offices. It may be sensible to disconnect such areas at the wiring closet. Consider using secure hubs and monitoring attempts to connect unauthorized hosts.

4.5.3 Other Network Technologies

Technologies considered here include X.25, ISDN, SMDS, DDS, and Frame Relay. All are provided via physical links that go through telephone exchanges, providing the potential for them to be diverted. Crackers are certainly interested in telephone switches as well as in data networks!

With switched technologies, use Permanent Virtual Circuits or Closed User Groups whenever this is possible. Technologies that provide authentication and encryption (such as IPv6) are evolving rapidly; consider using them on links where security is important.

4.5.4 Modems

4.5.4.1 Modem Lines Must Be Managed

Although they provide convenient access to a site for its users, they can also provide an effective detour around the site's firewalls. For this reason it is essential to maintain proper control of modems.

Do not allow users to install a modem line without proper authorization. This includes temporary installations (e.g., plugging a modem into a facsimile or telephone line overnight).

Maintain a register of all your modem lines and keep your register up-to-date. Conduct regular (ideally automated) site checks for unauthorized modems.

4.5.4.2 Dial-In Users Must Be Authenticated

A user name and password check should be completed before a user can access anything on your network. Normal password security considerations are particularly important (see the section "One-Time Passwords").

Remember that telephone lines can be tapped, and that it is quite easy to intercept messages to cellular phones. Modern high-speed modems use more-sophisticated modulation techniques, which makes them somewhat more difficult to monitor, but it is prudent to assume that hackers know how to eavesdrop on your lines. For this reason, you should use one-time passwords if at all possible.

It is helpful to have a single dial-in point (e.g., a single large modem pool) so that all users are authenticated in the same way.

Users will occasionally mistype a password. Set a short delay - two seconds, perhaps - after the first and second failed logins, and force a disconnect after the third. This will slow down automated password attacks. Do not tell the user whether the user name, the password, or both were incorrect.

4.5.4.3 Call-Back Capability

Some dial-in servers offer call-back facilities (i.e., the user dials in and is authenticated, then the system disconnects the call and calls back on a specified number). Call-back is useful because if someone guesses a user name and password, the system disconnects and then calls back the actual user whose password was cracked; random calls from a server are suspicious, at best. This does mean users may only log in from one location (where the server is configured to dial them back), and of course there may be phone charges associated with the call-back location.

This feature should be used with caution; it can easily be bypassed. At a minimum, make sure that the return call is never made from the same modem as the incoming one. Overall, although call-back can improve modem security, you should not depend on it alone.

4.5.4.4 All Logins Should Be Logged

All logins, whether successful or unsuccessful, should be logged. However, do not keep correct passwords in the log. Rather, log them simply as a successful login attempt. Because most bad passwords are mistyped by authorized users, they only vary by a single character from the actual password. Therefore, if you cannot keep such a log secure, do not log it at all.

If Calling Line Identification is available, take advantage of it by recording the calling number for each login attempt. Be sensitive to the privacy issues raised by Calling Line Identification. Also be aware that Calling Line Identification is not to be trusted (because intruders have been known to break into phone switches and forward phone numbers or make other changes); use the data for informational purposes only, not for authentication.

4.5.4.5 Choose Your Opening Banner Carefully

Many sites use a system default contained in a message-of-the-day file for their opening banner. Unfortunately, this often includes the type of host hardware or operating system present on the host. This can provide valuable information to a would-be intruder. Instead, each site should create its own specific login banner, taking care to only include necessary information.

Display a short banner but do not offer an "inviting" name (e.g., University of XYZ, Student Records System). Instead, give your site name, a short warning that sessions may be monitored, and a user name/password prompt. Verify possible legal issues related to the text you put into the banner.

For high-security applications, consider using a "blind" password (i.e., give no response to an incoming call until the user has typed in a password). This effectively simulates a dead modem.

4.5.4.6 Dial-Out Authentication

Dial-out users should also be authenticated, particularly because your site will have to pay the telephone charges.

Never allow dial-out from an unauthenticated dial-in call, and consider whether you will allow it from an authenticated one. The goal here is to prevent callers using your modem pool as part of a chain of logins. This can be hard to detect, particularly if a hacker sets up a path through several hosts on your site.

At a minimum, do not allow the same modems and phone lines to be used for both dial-in and dial-out. This can be implemented easily if you run separate dial-in and dial-out modem pools.

4.5.4.7 Make Your Modem Programming as "Bullet-Proof" as Possible

Be sure modems cannot be reprogrammed while they are in service. At a minimum, make sure that three plus signs will not put your dial-in modems into command mode!

Program your modems to reset to your standard configuration at the start of each new call. Failing this, make them reset at the end of each call. This precaution will protect you against accidental reprogramming of your modems. Resetting at both the end and the beginning of each call will assure an even higher level of confidence that a new caller will not inherit a previous caller's session.

Check that your modems terminate calls cleanly. When a user logs out from an access server, verify that the server hangs up the phone line properly. It is equally important that the server forces logouts from whatever sessions were active if the user hangs up unexpectedly.

4.6 Auditing

This section covers the procedures for collecting data generated by network activity, which may be useful in analyzing the security of a network and responding to security incidents.

4.6.1 What to Collect

Audit data should include any attempt to achieve a different security level by any person, process, or other entity in the network. This includes login and logout, super-user access (or the non-UNIX equivalent), ticket generation (for Kerberos, for example), and any other change of access or status. It is especially important to note "anonymous" or "guest" access to public servers.

The actual data to collect will differ for different sites and for different types of access changes within a site. In general, the information you want to collect includes user name and host name for login and logout; previous and new access rights for a change of access rights; and a timestamp. Of course, there is much more information that might be gathered, depending on what the system makes available and how much space is available to store that information.

One very important note: Do not gather passwords. This creates an enormous potential security breach if the audit records should be improperly accessed. Do not gather incorrect passwords either, as they often differ from valid passwords by only a single character or transposition.

4.6.2 Collection Process

The collection process should be enacted by the host or resource being accessed. Depending on the importance of the data and the need to have it local in instances in which services are being denied, data could be kept local to the resource until needed or be transmitted to storage after each event.

There are basically three ways to store audit records: in a read/write file on a host, on a write-once/read-many device (e.g., a CD-ROM or a specially configured tape drive), or on a write-only device (e.g., a line printer). Each method has advantages and disadvantages.

File system logging is the least resource-intensive of the three methods and the easiest to configure. It allows instant access to the records for analysis, which may be important if an attack is in progress. File system logging is also the least-reliable method. If the logging host has been compromised, the file system is usually the first thing to go; an intruder could easily cover up traces of the intrusion.

Collecting audit data on a write-once device takes slightly more effort to configure than a simple file, but it has the significant advantage of greatly increased security because an intruder could not alter the data showing that an intrusion has occurred. The disadvantage of this method is the need to maintain a supply of storage media and the cost of that media. Also, the data may not be instantly available.

Line printer logging is useful in systems where permanent and immediate logs are required. A real-time system is an example of this, where the exact point of failure or attack must be recorded. A laser printer or other device that buffers data (e.g., a print server) may suffer from lost data if buffers contain the needed data at a critical instant. The disadvantage of paper trails is the need to keep the printer fed and the need to scan records by hand. There is also the issue of where to store the potentially enormous volume of paper that may be generated.

For each of the logging methods described, there is also the issue of securing the path between the device generating the log and actual logging device (i.e., the file server, tape/CD-ROM drive, printer).

If that path is compromised, logging can be stopped or spoofed or both. In an ideal world, the logging device would be directly attached by a single, simple point-to-point cable. Because that is usually impractical, the path should pass through the minimum number of networks and routers. Even if logs can be blocked, spoofing can be prevented with cryptographic checksums (it probably is not necessary to encrypt the logs because they should not contain sensitive information in the first place).

4.6.3 Collection Load

Collecting audit data may result in a rapid accumulation of bytes, so storage availability for this information must be considered in advance. There are a few ways to reduce the required storage space. First, data can be compressed, using one of many methods, or the required space can be minimized by keeping data for a shorter period of time with only summaries of that data kept in long-term archives. One major drawback to the latter method involves incident response. Often, an incident has been ongoing for some period of time when a site notices it and begins to investigate. At that point in time, it is very helpful to have detailed audit logs available. If these are just summaries, there may not be sufficient detail to fully handle the incident.

4.6.4 Handling and Preserving Audit Data

Audit data should be some of the most carefully secured data at the site and in the backups. If an intruder were to gain access to audit logs, the systems themselves in addition to the data would be at risk.

Audit data may also be crucial to the investigation, apprehension, and prosecution of the perpetrator of an incident. For this reason, it is advisable to seek the advice of legal council when deciding how audit data should be treated. This should happen before an incident occurs.

If a data-handling plan is not adequately defined prior to an incident, it may mean that there is no recourse in the aftermath of an event, and it may create liability resulting from improper treatment of the data.

4.6.5 Legal Considerations

Due to the content of audit data, there are a number of legal questions that arise that might need to be addressed by your legal counsel. If you collect and save audit data, you need to be prepared for consequences resulting both from its existence and its content.

One area concerns the privacy of individuals. In certain instances, audit data may contain personal information. Searching through the data, even for a routine check of the system's security, could represent an invasion of privacy.

A second area of concern involves knowledge of intrusive behavior originating from your site. If an organization keeps audit data, is it responsible for examining it to search for incidents? If a host in one organization is used as a launching point for an attack against another organization, can the second organization use the audit data of the first organization to prove negligence on the part of that organization?

These examples are meant to be comprehensive but should motivate your organization to consider the legal issues involved with audit data.

4.7 Securing Backups

The procedure of creating backups is a classic part of operating a computer system. Within the context of this document, backups are addressed as part of the overall security plan of a site. There are several aspects to backups that are important within this context:

Make sure your site is creating backups.
Make sure your site is using offsite storage for backups. The storage site should be carefully selected for both its security and its availability.
Consider encrypting your backups to provide additional protection of the information once it is offsite. However, be aware that you will need a good key management scheme so that you will be able to recover data at any point in the future. Also, make sure you will have access to the necessary decryption programs at such time in the future as you need to perform the decryption.
Do not always assume that your backups are good. There have been many instances of computer security incidents that have gone on for long periods of time before a site has noticed the incident. In such cases, backups of the affected systems are also tainted.
Periodically verify the correctness and completeness of your backups.

^[3]CERT is registered in the U.S. Patent and Trademark Office.

< Day Day Up >