 |
Home | Search | Browse | About IPO | Staff | Links |
|
Home | Search | Browse | About IPO | Staff | Links |
|
Security and the New ILLINET Online System Frank Cervone With the introduction of a new online union catalog for ILLINET Online, all types of issues arise. For the most part, these issues relate to its implementation: what will be indexed, how it will be displayed, what are the indicators of a successful data conversion, and other such concerns. With the introduction of the DRA system, otherwise known as "new IO," a new networking infrastructure is also being introduced. Because of this, a whole new set of issues related to networking must be dealt with by each of the participating libraries. This article will address one aspect of these new challenges: security in the new networked environment. The issues related to security are complex and multifaceted. In addition to general concepts related to security and networks, there are technical considerations at the workstation, LAN server and web server levels. Finally, the human-computer interaction dimension must always be considered when implementing a security system. What is a Security System? Before trying to define what the components of a good security system implementation are, it might be helpful to decide what the purpose of a security system is. A computer security system is designed around three purposes:1 1. to prevent the unauthorized release of information, An unfortunate fact is that implementing a security system is hard. It is hard because in many cases the security plan cannot be tested.2 A system cannot be tested against the latest virus, because it is not known what that virus is. A system cannot be tested against the latest password file cracking program, because those programs are not generally made available to security administrators. But does this mean that the battle is lost? No, because technological solutions can be put into place to test most common security problems and exposure points. Some of the same solutions also can be used to secure the system after testing. Policies and procedures can be put into place that proactively help determine when suspicious activity is occurring. This last point is important because the biggest problem in most security system implementations is that it is generally not known if the security system is adequate. As a result, most security problems are dealt with in a reactive rather than proactive mode. This does not allow a site to operate from a position of strength. In the new networked environment of ILLINET Online, it will be to every library's advantage to deal with security proactively, that is, before problems occur, because the consequences can be very dire. On the other hand, reasonable expectations should be made of the security system. No security system, no matter how good or complete, is foolproof or failsafe. The best any system administrator can do is make a diligent effort to secure the system and minimize the potential risk if compromised.3 The Aspects of a Security System In a good security system, eight aspects of control are present. The first is individual authorization. Simply put, this means one person, one login to the system. This is a requirement for staff functions; generic logins are simply not acceptable. However, individual logins in the public access environment may not be possible or feasible. It would be impractical, although certainly not impossible, for a library to give a unique system login to each patron. But another, relatively secure alternative is available. Each public machine can have a unique login to the network. The advantage to this scheme is that if a problem should arise, the problem can be traced back to the machine of origin rather than a generic set of machines with a "public" or "guest" I.D. 117 The second aspect is access control. Every user on the system is not equal. Some functions are restricted to catalogers, some are restricted to the circulation desk, and some may be restricted to the reference desk. User definitions should be constructed so they give access to those functions necessary for the person to complete a job, duty or activity and nothing more. Individual authorization without appropriate limits on access control are essentially worthless.4 The third aspect relates to the audit trails a system produces. Almost every server operating system produces a log of successful and unsuccessful logins to the system. Logoffs are also tracked. In some cases, the programs that are used during the session are tracked as well. Although monitoring the access habits of staff and patrons raises significant moral issues and is not the point of a security system, the use of these types of audit trails in security systems is usually a requirement. Note that this type of monitoring does not record the search strategies of a patron, nor does it record the valid actions a patron might take. For example, it would not be possible to recreate the load records of a patron from these activity logs. And given the inordinate amount of data the audit trails produce, they are generally only useful for monitoring exceptions: the user that attempts to login 20 times with an incorrect password, a dial-in port that has an unusually high amount of activity, requests to access privileged system programs that are not generally available to users at a public workstation. Audit trails are used to monitor all these situations, which in turn may indicate a security problem exists. Physical security is the fourth aspect of a security program. Servers should not be in public areas. This includes placing servers in areas where unauthorized staff can gain easy access to them. For example, the Novell NetWare operating system does not provide a way to secure the system console. If the console were located in an insecure area, such as the middle of technical services or the reference department, anyone could walk up to the console, type "down" at the prompt, and cause a significant network disruption. Servers should always be physically secured in areas that are locked and have restricted access.5 Disaster recovery, the fifth aspect of the plan, is often the most overlooked. All servers should be backed up on a regular basis. Several generations of backup should be kept and stored in disbursed locations. At the very least, one of the backup generations should be removed from the site of the server. Equally, if not more important, is that the backup and disaster recovery plan must be tested. The best and most thorough disaster recovery plan is absolutely useless if it has not been tested and demonstrated. A disaster recovery test must be done after every change to the system (e.g., if a new disk drive is added to the server, the security administrator must make sure the old backups still work in addition to the new ones). The sixth aspect of the security plan concerns protection of remote access points. Does the network support dial-in modems? Telnet? Ftp? What are the precautions being taken to ensure these are only accessible by authorized users and purposes? What precautions are in place to ensure that someone does not install a modem on their local machine, which inadvertently (or advertently) allows inappropriate access to your internal network? Software discipline concerns control and rigor in software implementation and crosses over into both the administration and system development functions. Procedures must be in place to prevent the introduction of viruses into the network. Procedures must also be in place to detect and remove viruses that are introduced to the network despite previous precautions. A systematic method of installing and upgrading software must be articulated regardless of whether the software is from a third party or developed in-house. Commonly referred to as change control, this is a particularly important aspect of security. If it is not known what is supposed to be on the system, how can one know when it has changed?6 System assessment is the last aspect of the security program and is predicated on software discipline. System assessment can be summarized as the continuous evaluation of the system in relationship to the effectiveness of current procedures, possible exposures and potential risks. This evaluation leads to modifications and additions to the security plan that reflect the changing conditions under which the network is used. Common Fallacies Used to Justify Not Implementing a Security System: • We can't afford it. No site is too small to implement security; no site has perfect users; and the costs of a security breach are far greater than those of implementing a security system. Security does not have to be exorbitantly expensive. By using common sense in applying the tools of the system and freely available shareware, many sites can implement a completely adequate security system without additional outlays for software. Security programs prevent inadvertent, as well as intentional, misuse or corruption of the system. Even in a perfect world, people make mistakes. Security policies and procedures help ensure those mistakes do not cause catastrophic system failure. 118 Any site is worthy of a hacker's attention, if for no other reason than the site being used as a stepping stone to bigger and better sites. All sites are at risk. Workstation Considerations: There are three major issues regarding security of workstations: preventing viral infections, maintaining workstation configurations, and patron confidentiality. Viruses are programs that corrupt the data or configuration of the PC and sometimes the network. Defense against viruses can be performed at both the hardware and software level. At the software level, the best defense against viruses is to install an anti-viral program. Several are available and most allow for a free download for testing purposes. At the hardware level, two precautions are strongly recommended. First, modify the hardware (BIOS) settings on all computers to prevent booting from floppy disks. This will prevent the majority of virus infections because the vast majority of PC infections still come from floppy disks. Second, prevent writing to the boot sector of the hard drive. This will disable any virus that tries to destroy the hard drive by modifying the area of the disk from which the operating system loads. This is the most common type of viral infection. Windows NT provides native security features7, which makes it a good choice for machines in public areas. Because Windows NT is required for staff functionality in DRA, an additional benefit of using Windows NT in public areas is a single platform for both staff and public machines. But Windows NT requires more resources than a Windows 95 machine, so many libraries may want to use Windows 95 on their public machines even though Windows 95 does not provide much native support for comprehensive security.8 One method of securing Windows 95 machines is to have the machines boot and run all software from protected directories on the network. This provides the user with a secure environment that minimizes the chance of viral infection and the system administrator with an environment that minimizes the wanton disruption of the machine configuration. The downside of this arrangement is that it generates a great deal of network traffic. In many situations, the amount of network traffic this configuration generates is unacceptable. If this first scenario is not feasible, an add-on security package for Windows 95 must be used. Packages commonly used are Fortres 101, Stoplight ELS and WinShield. All these packages provide a basic level of security. The choice among the three is based on differences in functionality, philosophy of security and other subjective factors.
But, whichever operating system or security program is used, the following items should be considered during the planning of the security program: How will directories and files on the hard drive be protected from alteration or removal? How will the creation of new files on the hard drive be prevented? How will the desktop configuration be protected? How will the system prohibit execution of unauthorized programs? The other major issue related to the client PC is the configuration of the web browser. Assuming that the PC has been adequately protected with security software, the remaining questions are related to protecting the confidentiality of users and prohibiting mail spoofing. Protecting the confidentiality of users is one of the more difficult issues when dealing with Web browsers. The is especially true when users at public stations are not required to use individual logins. Given that Web browsers are designed to be used by one user, they do not contain mechanisms that make flushing the history of visited pages easy. If a user is required to login, a scripted procedure can be invoked before Netscape or Internet Explorer is started that flushes the information left behind by a prior user. However, in situations where this is not possible, the problem can be ameliorated somewhat by turning caching off at the browser level and setting document verification to the "every time" setting. This imposes a performance penalty, because pages must be reloaded each time they are visited, but it stops the next patron from viewing confidential information belonging to a prior patron simply by hitting the "back" button on the browser. Mail spoofing is the process whereby a user sends mail from an e-mail address that does not belong to them. This is amazingly easy to do. Because anonymous, harassing mail from the library is not good, many libraries prohibit mail services that cannot be authenticated. In Internet Explorer, it is simple to exclude e-mail functionality from the browser; simply don't install it. In Netscape, this is more difficult because the e-mail interface is installed whether it is wanted or not. For Netscape then, an approach often taken is to configure a bogus mail server in the e-mail configuration parameters and then protect the configuration via the PC security system. This makes it difficult, although not impossible, to send mail because there is no way to connect to a valid mail server. A crafty user can still crack this scheme because the mail application is installed on the PC, but this does prevent a large majority of problems. Another way to disable functionality in a Web browser is to install kiosk software. Several packages are available, one of them being Ikiosk. A problem with this approach is that often the amount of functionality removed by the kiosk program is significant and affects the usability of the browser. 119 Another alternative is to edit the browser's executable file to remove the unwanted functions. There are several problems with this: 1. It is very easy to make a mistake and, therefore, not get the desired results, 2. Whenever a new version of the browser is released the changes must be reapplied, 3. New versions of the browser will probably require reworking of the changes that remove functionality, and 4. Even if the vendor tacitly approves of the procedure, and many do not, they will not provide any support whatsoever for the modified executable. In short, modifying executables is not a very good idea. Server Considerations On the local area network (LAN), the first concern is to ensure that users are always authenticated and have access only to those functions necessary to complete their work or tasks. How this is done varies from one network operating system (NOS) to another, but it should be the first area for investigation. When installed, most NOSes have security definitions that are far too liberal and inclusive. In almost all cases, these broad definitions constitute a significant exposure to the security of the system. The server can potentially do a number of different things; therefore, a number of services or dameons (as they are called on UNIX-based systems) run on the server. Depending on the function of the server, many of these services are not necessary (Table 1) and should be disabled.9 Authentication in many of these services is not rigorous (or even existent), so hackers use these services as entry points into systems. This is why it is so important that these unused or superfluous services be turned off. Some services that might be used, such as tftp and finger, are notoriously insecure and should be disabled as well. Required services, such as ftp, should be protected by comprehensive security mechanisms, such as tcp wrappers.10 Firewalls are used to protect a network from unwanted visitors by restricted incoming network traffic. They also can be used to prevent access to external sites, in which case they act more like a filter. Firewalls are a useful tool to protect from unwanted visitors, but they are only part of the equation. An unconfigured firewall is useless as protection from hackers. Depending on the required functionality, in library settings the configuration of firewalls can be difficult because all patrons generally do not come into the system from a known set of network workstations. One of the basic mechanisms used for protection via a firewall is that all incoming traffic comes from a predetermined set of stations. If confidential information (logins, SSN, personal data) is being transferred to a server, the use of a secure server should be seriously considered. A secure server (such as those provided by most commercial vendors) encrypts the transmissions between the client and the server over the network. Normally, all data on the Internet is sent in plain (that is, unencrypted) mode. It is extremely easy for a hacker to inspect the data stream to pick out the information (such as credit card number) they are interested in. The basic networking model of the Internet is very similar to that of a telephone party line, anyone that wants to can listen in. Since messages transmitted over the Internet can traverse many different network paths, it is impossible to know who or where a transmission might be "eavesdropped" on. In many applications, this is not really a problem. But for those applications that require greater security, a secure server, while not prohibiting monitoring of the transmission, does make it impossible for an interloper to decode the transmission. This makes it inherently much more secure.11 Web Server Considerations In addition to the other general concerns related to servers, a particular concern on Web servers is the definition of the directory structures. What does a Web server do? It facilitates a process that lets anyone look at files on the server. By definition, it is extremely important that those files on the server not significant to the content of the Web site be excluded from the Web site content. To facilitate this, most Web servers require that the administrator define where the head of the Web content hierarchy is. In all cases, the web content hierarchy should be a structure separate from the other directories and file systems on the machine. Furthermore, most web servers define a "default" file to look for whenever a directory name is supplied as a URL instead of a file name. In most cases, this default is either "index.htm" or "index.html." Whatever it is, make sure that this default file exists in every directory in the Web content hierarchy structure. Failing to ensure this is a well-known, easily exploited security exposure. If users are allowed to create home pages on their accounts, make sure the server is configured to only allow access to the server content portion of the user's directory. Most commonly, a subdirectory named public_html in the user's directory is used for delivering web content. Educate users that only Web content, and nothing sensitive or privileged, should be placed in the Web content subdirectory.12 If users are allowed to use cgi-scripts or other programming mechanisms, make sure a procedure is in 120 place to verify that all programs executed from the user's pages are secure. Typically, this means requiring that all programs be stored in a directory under the control of the system administrator. Before programs are moved into this directory, the system administrator should inspect for obvious (and not so obvious) security loopholes. Along the same lines, all file protection, such as requiring a user name and password to access all content pages, should be done at the server configuration level, not through local protection (.htaccess files) located in directories. The .htaccess file mechanism allows for the distribution of security information throughout the hierarchy of the server. Although this provides for some decentralized management of the Web server, it is also a well-known security hole that is (of course) easily exploitable.13 Human Aspects of Security Systems Ultimately, a security system is only as good as its implementation and use. Requiring users to supply passwords, but then not requiring password changes on a regular basis is about as effective as not requiring a password at all. On the other end of the spectrum, requiring users to use passwords that are so complex they must be written down to be remembered is just as fruitless an exercise. Security policies must be well defined and documented. Security administrators must understand all the steps involved in setting up a user or defining a new application. Education of users is especially important. This education must address: why security is important, how to log in and log off, and how and why changing passwords frequently is a good practice. This is only possible with good security policy documentation. When security is breached, sanctions must be in place and enforceable. A security policy without consequences for hostile or negligent behavior can never be effective. Furthermore, the policy must be equitable. All employees and patrons, at all levels, must be subject to the same rules and outcomes.
It is most important that the system administrator must understand the effects of the policies that he/she is implementing. Policies that are too restrictive, uncompromising or unreasonable given the situation, are open targets for subversion and sabotage. Going overboard in the implementation of security can be even more ineffective than having no security at all. Conclusion The implementation of the new union catalog is an exciting prospect for all libraries in Illinois. But it comes with new challenges. The issues of Web servers, client machine protection, networking and security are "old hat" for some libraries. But for just as many, if not more, this is a brand new area. In the excitement and activity that will go into implementing the new catalog, it is important that security precautions not be left out of the picture. Thinking about security now will alleviate problems later during the implementation and testing of "New IO." References 1. Anderson, J., "Information Security in a Multi-User Computer Environment," Advances in Computers, vol. 12, Academic Press, New York, NY, 1973. Vendor List
StopLight ELS at http://safetynet.com/ * Frank Cervone, Assistant Director for Systems, DePaul University Libraries; and Visiting Instructor, School for New Learning, DePaul University, Chicago. 121 Information Resources
CERT Tools
Firewalls Mailing List
A mailing list with information on firewalls: installation and maintenance
Newsgroups alt. security comp.risks
comp.security.announce
General information, comp. security, unix is better
Software Resources The following resources may be of interest to sites implementing a security program.
TCP wrapper and portmapper
Portmapper is used for RPC-specific services ftp://ftp.win.tue.nl/pub/security/tcp_wrapper* TIS Firewall Kit A set of software components and configuration recommendations that provide basic firewall support. ftp://ftp.tis.com/pub/firewalls/toolkit Swatch Logfile Monitor
For UNIX-based systems, allows actions to be associated with entries in the logfile, e.g., sending emergency email messages,etc.
SATAN A very popular network vulnerability auditing package. ftp://ftp.win.tue.nl/pub/security/satan.tar.Z Tripwire
Evaluates a system and allows for the monitoring of alterations to the system.
Crack
A tool for checking passwords and password files for vulnerabilities.
Table 1 — Internet Services that are Superfluous or Security Exposures
122 |
|
|